David Johnston <polobo@yahoo.com> writes:
> Tom Lane-2 wrote
>> you do have one conceptual error: anyarray to anyelement is supposed
>> to return the element type of the input array type. So when you pass
>> TEXT[] to this function, the SQL parser decides that the expected
>> result type is TEXT.
> While this is how it behaves in practice I did not find this described in
> the documentation.
No? What I read in
http://www.postgresql.org/docs/9.3/static/extend-type-system.html#EXTEND-TYPES-POLYMORPHIC
is:
Polymorphic arguments and results are tied to each other and are resolved
to a specific data type when a query calling a polymorphic function is
parsed. Each position (either argument or return value) declared as
anyelement is allowed to have any specific actual data type, but in any
given call they must all be the same actual type. Each position declared
as anyarray can have any array data type, but similarly they must all be
the same type. And similarly, positions declared as anyrange must all be
the same range type. Furthermore, if there are positions declared anyarray
and others declared anyelement, the actual array type in the anyarray
positions must be an array whose elements are the same type appearing in
the anyelement positions.
The last sentence is what I was saying, no?
You can if you like replace "anyelement" by "anynonarray", but that won't
change the semantics if there's also an occurrence of "anyarray", because
that's going to constrain the anyelement type to be something that has an
associated array type. (If we had arrays of arrays, then these two cases
might differ ... but we don't.)
FWIW, the original design for polymorphic functions didn't have
anynonarray, and we didn't particularly need it. My recollection is
that it's basically a kludge that we invented later to allow the text
concatenation and array concatenation versions of "||" to coexist.
regards, tom lane
