Re: RfD: more powerful "any" types - Mailing list pgsql-hackers

From Tom Lane
Subject Re: RfD: more powerful "any" types
Date
Msg-id 7344.1252612196@sss.pgh.pa.us
Whole thread Raw
In response to Re: RfD: more powerful "any" types  (Hannu Krosing <hannu@2ndQuadrant.com>)
Responses Re: RfD: more powerful "any" types
List pgsql-hackers
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.


> 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...)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: RfD: more powerful "any" types
Next
From: Hannu Krosing
Date:
Subject: Re: RfD: more powerful "any" types