Re: RfD: more powerful "any" types

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RfD: more powerful "any" types
Date: 2009-09-09 20:31:18
Message-ID: 1252528278.4080.18.camel@hvost1700
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-09 20:31:40 Re: RfD: more powerful "any" types
Previous Message Tom Lane 2009-09-09 20:27:05 Re: Ragged CSV import