Re: arrays over initdb-created types are broken after pg_upgrade

On Sun, Aug 9, 2026 at 1:41 PM Chengpeng Yan <chengpeng_yan(at)outlook(dot)com> wrote:
> > On Aug 6, 2026, at 18:34, John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
> >
> > I think it would work to restrict to true array types by adding "AND
> > e.typarray = t.oid" to the WHERE clause:
> >
> > SELECT t.oid FROM pg_catalog.pg_type t
> > JOIN pg_catalog.pg_type e ON t.typelem = e.oid
> > LEFT JOIN pg_catalog.pg_namespace n ON e.typnamespace = n.oid
> > WHERE t.typtype = 'b'
> > AND e.typarray = t.oid
> > AND ((e.oid >= 10000 AND e.oid < 16384)
> > OR n.nspname = 'information_schema')
>
> That seems reasonable for ordinary associated array types. One caveat
> is that a custom variable-length type can use `array_in`/`array_out` and
> store an `ArrayType` datum without being the element type's associated
> array. `e.typarray = t.oid` would not detect its embedded element OID.
> That said, such a type is probably very uncommon and may not need
> special handling.

That case doesn't make any sense to me -- can you construct a concrete
example and show what happens? In any case, it's more important here
to avoid false positives here than false negatives, especially given
the lack of field reports. For that reason, I'm also inclined to only
backpatch to v15, since v14 will be on it's last release with next
minor release this can affect.

--
John Naylor
Amazon Web Services