Re: RfD: more powerful "any" types
От | Pavel Stehule |
---|---|
Тема | Re: RfD: more powerful "any" types |
Дата | |
Msg-id | 162867790909091244j40efa2abnaa83cafff8e67ac3@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RfD: more powerful "any" types (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: RfD: more powerful "any" types
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
2009/9/9 Robert Haas <robertmhaas@gmail.com>: > On Wed, Sep 9, 2009 at 1:15 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote: >> Alvaro Herrera <alvherre@commandprompt.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
В списке pgsql-hackers по дате отправления: