From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Carlsen <plcplc(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: valid casts to anyarray |
Date: | 2023-09-27 14:50:24 |
Message-ID: | 606024.1695826224@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Philip Carlsen <plcplc(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Hill | 2023-09-27 15:55:23 | pg*.dll in psqlODBC have no version numbers |
Previous Message | Laurenz Albe | 2023-09-27 14:49:51 | Re: valid casts to anyarray |