Re: RfD: more powerful "any" types

2009/9/10 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Sep 10, 2009 at 4:43 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> 2009/9/10 Dimitri Fontaine <dfontaine(at)hi-media(dot)com>:
>>> Hannu Krosing <hannu(at)2ndQuadrant(dot)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
>