From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RfD: more powerful "any" types |
Date: | 2009-09-09 16:37:07 |
Message-ID: | F32546DF-8093-40D7-AA63-440842C6620D@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sep 9, 2009, at 6:39 AM, Tom Lane wrote:
> 1. Is a completely unconstrained argument type (ie "any") of any real
> use to PL functions, and if so how can we expose that usefulness?
> The only clear thing to do with such an argument is IS NULL/IS NOT
> NULL
> tests, which might or might not be worth the trouble.
If you can pass an "any" to pg_typeof(), it's possible for functions
to determine the types of arguments themselves and then to decide what
to do with them (cast, etc.). I can see no reason not to give this
ability to function authors, can you?
> 2. Is there any use for arguments with type constraints not covered
> by the existing ANYFOO rules, and if so what do we add for that?
>
> One comment on point 2 is that it was foreseen from the beginning
> that there would be need for ANYELEMENT2 etc, and I'm actually rather
> surprised that we've gone this long without adding them. Alvaro made
> a good point about not wanting to multiply the various hard-wired
> OID references, but perhaps some judicious code refactoring could
> prevent a notational disaster.
The difference between allowing ANYELEMENT2, ANYELEMENT3, ANYELEMENT .
++$i and allowing "any" escapes me.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | decibel | 2009-09-09 16:41:38 | Re: RfD: more powerful "any" types |
Previous Message | decibel | 2009-09-09 16:30:35 | Re: Elementary dependency look-up |