Re: valid casts to anyarray

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

In response to

Responses

Browse pgsql-general by date

  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