Philip Carlsen <plcplc@xxxxxxxxx> 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
