From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RfD: more powerful "any" types |
Date: | 2009-09-10 20:38:25 |
Message-ID: | 1252615105.3931.47.camel@hvost1700 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
> Hannu Krosing <hannu(at)2ndQuadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-09-10 20:43:47 | Re: RfD: more powerful "any" types |
Previous Message | Aidan Van Dyk | 2009-09-10 20:33:38 | Re: RfD: more powerful "any" types |