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 19:37:02
Message-ID: 16914.1057001822@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:

+ * The rules for this resolution are as follows:
+ * 1) if the context type is polymorphic, punt and return type_to_resolve
+ * unchanged
+ * 2) if type_to_resolve is ANYARRAY (polymorphic), then return context_type
+ * if it is already an array type, or get its array type if not
+ * 3) if type_to_resolve is ANYELEMENT (polymorphic), then return context_type
+ * if it is already an elemental type, or get its element type if not
+ * 4) if type_to_resolve is non-polymorphic, return it unchanged
+ */
+ Oid
+ resolve_type(Oid type_to_resolve, Oid context_type)

This seems wrong. ANYELEMENT doesn't imply conversion from array to
element type. I don't think you're giving resolve_type nearly enough
context to produce a correct answer.

[ thinks for a bit ]

Bearing in mind that the result type of the transfn must equal its first
input type, ISTM there are only four interesting cases for polymorphic
transfer functions:
transfn(anyelement, anyelement) returns anyelement
transfn(anyelement, anyarray) returns anyelement
transfn(anyarray, anyelement) returns anyarray
transfn(anyarray, anyarray) returns anyarray
Per our previous discussion, other cases (such as single-input transfn
or non-polymorphic second input type) can be rejected by CREATE AGGREGATE
since there'd be no way to resolve the actual transfer state type.

Knowing which of these four cases you have, you can correctly derive the
actual state type from the actual aggregate input type, namely
1. same as input type (no restrictions on what it is)
2. element type of input (which must be an array type)
3. array type with input as element (there must be one)
4. input type, but first check it's an array
You're not providing enough info to resolve_type to let it handle all
four cases correctly. In any case, this procedure seems exceedingly
specific to the problem of resolving aggregate internal types. I doubt
it should be in parse_type at all, and it certainly shouldn't have a
name as generic as resolve_type.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2003-06-30 19:37:39 Re: Is Patch Ok for deferred trigger disk queue?
Previous Message Kevin Jacobs 2003-06-30 19:02:06 Re: PlPython

Browse pgsql-patches by date

  From Date Subject
Next Message Joe Conway 2003-06-30 19:55:44 Re: [HACKERS] Missing array support
Previous Message Joe Conway 2003-06-30 18:40:47 Re: polymorphic arguments and return type for PL/pgSQL