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
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 |
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) |