Re: RfD: more powerful "any" types - Mailing list pgsql-hackers

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.

...Robert