On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
> Hannu Krosing <hannu@2ndQuadrant.com> writes:
> > On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
> >> It might be possible to make it work, but it's likely to create a lot
> >> of bloat in pg_type, and will make it very difficult to implement
> >> features such as anonymous functions (i.e. LAMBDA).
>
> > For functions, anonymous does not mean "impossible to identify" ;)
>
> > If it is something (semi)-permanent we should store it in pg_type and id
> > it by oid, if it is really, really transient (say a closure generated
> > upper in the function chain) we can probably assign it some kind of
> > temporary, per-process oid for the duration of its existence
>
> Right. See what we do for anonymous composite types.
>
>
> > we could also change parser and translate reserved word ANY to typename
> > "any" .
>
> ANY is a reserved word for good and sufficient reasons. "Change the
> parser" is not an answer.
I suspect that alt least in some early SQL parsers all type names were reserved.
Or do you see a possible conflict here ?
What way can ANY be used in function type definition ?
> > 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.
>
> Excellent point. This would be an argument in favor of the typmod
> approach (and not counting typmod as something that makes two functions
> distinct...)
this seems like an elegant solution.
OTOH we still have a more compliacted case of
f(a anyelement1, b anyelement1, c anyelement2)
and
f(a anyelement1, b anyelement2, c anyelement2)
which may not be solved by non-differentiating typmod
>
> regards, tom lane
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability Services, Consulting and Training
