Re: RfD: more powerful "any" types

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 19:10:53
Message-ID: 603c8f070909091210g590733dfmc6e523a09e221ad5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

</handwaving>

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2009-09-09 19:16:38 Re: CTE bug?
Previous Message Tom Lane 2009-09-09 19:04:25 Re: More robust pg_hba.conf parsing/error logging