Re: RfD: more powerful "any" types
От | Pavel Stehule |
---|---|
Тема | Re: RfD: more powerful "any" types |
Дата | |
Msg-id | 162867790909101410k475841c6s4e65f5f08e8f6d98@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RfD: more powerful "any" types (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
2009/9/10 Robert Haas <robertmhaas@gmail.com>: > On Thu, Sep 10, 2009 at 4:43 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote: >> 2009/9/10 Dimitri Fontaine <dfontaine@hi-media.com>: >>> Hannu Krosing <hannu@2ndQuadrant.com> writes: >>>>> > 5. Various syntactic sugar to substitute for anyelement. (Not in favor >>>>> > of this myself, it seems to just complicate matters.) >>>>> >>>>> I agree; I don't think this solves any real problem. >>>> >>>> agreed, it does not solve the underlying problem, just may make it >>>> easier to understand and remember for users. >>> >>> Well, depends. I'm not convinced that abusing typmods for solving this >>> is a good idea, but it's just feeling. Having the same syntax covers >>> different semantics depending on the context is like interpreting data >>> in a column in different ways, and is on Josh's list of things to do if >>> you wanna wreck your database. >>> >>>> f(a anyelement1, b anyelement2) and f(a anyelement2, b anyelement1) >>>> >>>> seem to be different but actually are not, so we will need to handle >>>> multiple anyelementN types separately from ordinary types. >>> >>> Here for example you see that typmod on anyelement would mean something >>> entirely different from typmod on, say, numeric. >>> >>> This looks like a ugly hack. >>> >>>> ANY [TYPE] and SAME AS [TYPE OF] are syntactic sugar indeed, but they >>>> are much more SQL-like than needing to write "any" or anyelement(n) as >>>> argument type or return type >>> >> >> it's less confusing, than abstract types. And really nicer. >> >> SQL have to be readable for non hard developers too. And this is >> readable. Much more than anylement(1) or anyelement(n). >> >>> Not only it looks SQL'ish, but it'll be easier to document and use. And >>> it won't taint typmods, which still need a refactor to better handle >>> PostGIS needs, btw... >>> >>> >>> Now there's still the issue of having first class functions: that means >>> we'd be able to store them, have anonymous (lambda) functions (see the >>> DO command discussion), higher order function, and open the road to >>> generic function support. All that jazz is being pushed back with the >>> very natural counter argument: what good is there for having this in >>> your SQL database? >>> >>> So for people on the list who really want to push towards those things, >>> I suppose providing realistic use cases (how it would simplify this hack >>> you're maintaining in production) would allow for better exchanges :) >> >> I am fully agree > > So submit it as a follow-on patch and it can be discussed. It still > has to translate into some other construct (like anyelement2 or > anyelement(2)) internally, so we might as well do those first before > worrying about the rest of it. I sent more general patch. It's irony. I thing, so syntax ANY [TYPE] and SAME AS [TYPE OF] is good, very good. But it works only for functions with fixed argument numbers, so real usage isn't big. Minimum we need third kind - COMMON TYPE OF (variables). This patch will be very large - it needs big change of pg_proc :( Regards Pavel > > ...Robert >
В списке pgsql-hackers по дате отправления: