Joe Conway <mail@joeconway.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
