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
