Re: SQL99 ARRAY support proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQL99 ARRAY support proposal
Date
Msg-id 25821.1047243345@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL99 ARRAY support proposal  (Joe Conway <mail@joeconway.com>)
Responses Re: SQL99 ARRAY support proposal
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> Tom Lane wrote:
>> It would take some hackery to propagate the destination type down into
>> the ARRAY[] before the latter's type resolution is done, but at least
>> it'd be a quite localized hack.

> OK -- I'll try to make that work. I presume that in the non-specified 
> case "ARRAY[1,2,3]" I should use something similar to UNION's resolution 
> rules?

Yeah, that'd make sense to me.

>>> [...lots of good ideas regarding generalizing array operations...]

> I played with generalizing array functions a bit for plr and ran into 
> some problems (which I can't specifically recall at the moment), but 
> clearly that's the way to go. I'll start playing with your suggestions 
> in C code, and report back for more feedback as it solidifies.

It'd be useful if you can reconstruct what problems you ran into.


After more thought I'm thinking that we should specify these pseudotypes
like so: a given set of actual operand types matches an
operator/function whose definition uses ANYARRAY or ANYELEMENT only if
the same element type is involved at all positions.  Thus inANYARRAY = ANYARRAY
the left and right operands must be the same array type (so we preserve
the existing parse-time check, but we only need one pg_operator entry
to do it).  ForANYARRAY || ANYELEMENT
we get the desired behavior.  And there are some other interesting
possibilities: for example, a function could be declaredfoo(ANY, ANYELEMENT, ANYELEMENT)
which would mean that it takes any three datatypes, but the second
and third arguments have to be the same datatype.

If we run into limitations of this scheme, it could be generalized
further by adding pseudotypes ANYARRAY2 and ANYELEMENT2 that have
the same restriction among themselves, but are independent of
ANYARRAY/ANYELEMENT.  Then for examplefoo(ANYELEMENT, ANYELEMENT, ANYELEMENT2, ANYELEMENT2)
takes four params that can be anything so long as the first two are
the same datatype and the second two are also the same datatype (but
possibly a different type from the first two).  And you could add
ANYARRAY3, etc, till you got bored.  But I'd not bother with this
until someone showed a concrete need for it.  At the moment, the
useful examples I can think of don't need more than one "free variable"
in their set of argument datatypes.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Cursors and backwards scans and SCROLL
Next
From: Josh Berkus
Date:
Subject: Re: [SQL] Cursors and backwards scans and SCROLL