"David E. Wheeler" <da...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers