Re: RfD: more powerful "any" types

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