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
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 :)
Regards,
--
dim
