On Sep 9, 2009, at 10:04 AM, Tom Lane wrote:
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.
Security holes? Huh? What security holes would there be that you don't
already have with anyelement?
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.
I see. Yes, that is nice. Thanks for the examples.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
