Re: RfD: more powerful "any" types

2009/9/9 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Wed, Sep 9, 2009 at 1:15 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>>> Another possible example is sprintf:
>>
>>> create function sprintf(text, anyelement, anyelement2, anyelement3, ...)
>>> returns text
>>
>>> In order for this to work in general, we'd need FUNC_MAX_ARGS different
>>> types, which is currently defined as 100 in our code.
>>
>> But here, "any" would work perfectly fine, since there's no need for
>> any two arguments to be tied to each other or the result.
>>
>> Given that we've got away so far with only 1 instance of anyelement,
>> I'm not really convinced that there's a market for more than anyelement2
>> (and anyarray2, etc).
>
> I'm going to go out on a limb and say that if we're going to bother
> changing the status quo, we ought to create a reasonable number of
> these - maybe, say, four.  I can't see needing a hundred of these, but
> I don't think that we should assume that our inability to think of a
> use for more than two at the moment implies that there can never be
> one.
>
> Really, I think we need a type system that doesn't try to represent
> every type as a 32-bit integer.  Right now, for example, there's no
> reasonable way to write a function that takes another function as an
> argument.  What we need is a system where base types are represented
> by an OID, but derived types (list and functional types) are built up
> using type constructors that take other types as arguments.  So you
> could have a types like list(integer) or list(anyelement) or
> function(integer,bool) [meaning either taking an integer and returning
> a bool, or the other way around, depending on your notational
> preference].  Then you can have functions with complex types like:
>
> maplist : function(anyelement,anyelement2,function(list(anyelement),list(anyelement2)))
>
> This would have the fringe benefit of eliminating types like anyarray
> (which is just list(anyelement)) and the need to list every type twice
> in pg_type, once for the base type and once for the derived array
> type.

it would be nice, but probably it could significant increase parsing
query time. And this is +/- equal to what my transformationHook does.

regards
Pavel Stehule

>
> </handwaving>
>
> ...Robert
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>