Re: SQL99 ARRAY support proposal

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SQL99 ARRAY support proposal
Дата
Msg-id 25821.1047243345@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SQL99 ARRAY support proposal  (Joe Conway <mail@joeconway.com>)
Ответы Re: SQL99 ARRAY support proposal  (Joe Conway <mail@joeconway.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Cursors and backwards scans and SCROLL
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: [SQL] Cursors and backwards scans and SCROLL