Re: [HACKERS] Missing array support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Missing array support
Date: 2003-06-30 20:50:21
Message-ID: 17396.1057006221@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Joe Conway <mail(at)joeconway(dot)com> writes:
> Are you referring to ANYELEMENT actually being an array at runtime?
> That's the first time I've heard that concept.

That was the behavior we agreed to some time ago, to avoid needing
to entangle ANY into the polymorphism logic. See the comments for
check_generic_type_consistency:

* The argument consistency rules are:
*
* 1) All arguments declared ANYARRAY must have matching datatypes,
* and must in fact be varlena arrays.
* 2) All arguments declared ANYELEMENT must have matching datatypes.
* 3) If there are arguments of both ANYELEMENT and ANYARRAY, make sure
* the actual ANYELEMENT datatype is in fact the element type for
* the actual ANYARRAY datatype.

If only ANYELEMENT and not ANYARRAY appears in a function declaration,
then it can stand for any type, because only rule 2 applies. (The
difference from ANY is that multiple occurences of ANYELEMENT are all
constrained to stand for the same type.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message elein 2003-06-30 20:58:27 Re: PlPython
Previous Message Tom Lane 2003-06-30 20:45:50 Re: PlPython

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2003-06-30 21:05:45 Re: [HACKERS] Missing array support
Previous Message Aizaz Ahmed 2003-06-30 20:43:13 Patch for listing runtime option details through server executable (pg_guc)