Philip Carlsen <plcplc@gmail.com> writes:
> I've been down a rabbit hole today trying to understand what exactly makes
> a type a valid candidate for an ANYARRAY function argument (e.g., something
> you can 'unnest()').
Per the comments for check_generic_type_consistency:
* 2) All arguments declared ANYARRAY must have the same datatype,
* which must be a varlena array type.
If you follow that code down you eventually find that it expects
get_element_type() to succeed, and that says
* NB: this only succeeds for "true" arrays having array_subscript_handler
* as typsubscript. For other types, InvalidOid is returned independently
* of whether they have typelem or typsubscript set.
which is mechanized as an IsTrueArrayType() check.
> My reading has led me across such functions as 'get_promoted_array_type',
> 'IsTrueArrayType', 'can_coerce_type', and 'check_generic_type_consistency',
> and this has led me to believe that any type which has a valid (i.e.,
> non-zero?) pg_type.typelem defined should be applicable.
It has to not only have an element type, but have a standard array
header, else we don't know how to do a lot of operations on it.
Type "point" and related animals are sort of a poor man's array,
which is supported for basic subscripting operations, but it's not
generic enough to be reasonable to consider as an ANYARRAY.
regards, tom lane