Re: RfD: more powerful "any" types - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: RfD: more powerful "any" types
Date
Msg-id 1252528278.4080.18.camel@hvost1700
Whole thread Raw
In response to Re: RfD: more powerful "any" types  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, 2009-09-09 at 15:10 -0400, Robert Haas wrote:
> 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.

There is nothing that prevents us from representing those by an OID as
well.

Though how to define and store those in pg_type is another issue. 

>   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.
> 
> </handwaving>
> 
> ...Robert

-- 
Hannu Krosing   http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability   Services, Consulting and Training




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Ragged CSV import
Next
From: Tom Lane
Date:
Subject: Re: RfD: more powerful "any" types