Re: RfD: more powerful "any" types

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

regards
Pavel

>
> Regards,
> --
> dim
>