"David E. Wheeler" <david@kineticode.com> writes:
> 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?
Well, yeah: it looks like a fertile source of security holes, not to
mention implementation difficulties (plpgsql really wants well-typed
expressions...). What you can do at the C level is not necessarily
sane to give to PL authors. I'm willing to consider a carefully spec'd
out proposal in this area, but "open the floodgates" ain't it.
> The difference between allowing ANYELEMENT2, ANYELEMENT3, ANYELEMENT .
> ++$i and allowing "any" escapes me.
In an example like
create function foo (anyelement, anyelement2, anyelement2)returns anyarray2
the second and third arguments would be tied to be of the same type,
and the result would be an array of that type; whereas the first
argument's type is unrelated. "any" doesn't give you any inter-argument
constraints nor any way to define the result type in terms of the
argument types. For a possibly realistic example, consider a function
defined as "locate the element of an array that equals the search
argument, and return the corresponding element of a second array, which
is possibly of a different type". This could be defined as
create function search_array (val anyelement, search_array anyarray,
result_array anyarray2)returns anyelement2
but "any" isn't nearly expressive enough.
regards, tom lane
