Re: RfD: more powerful "any" types

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