Re: arrays over initdb-created types are broken after pg_upgrade - Mailing list pgsql-hackers

From Chengpeng Yan
Subject Re: arrays over initdb-created types are broken after pg_upgrade
Date
Msg-id CCF87C02-3D54-4B5A-A976-4081293FC53A@outlook.com
Whole thread
In response to arrays over initdb-created types are broken after pg_upgrade  (John Naylor <johncnaylorls@gmail.com>)
Responses Re: Fix unqualified catalog references in psql describe queries
List pgsql-hackers
Hi John,

> On Aug 6, 2026, at 18:34, John Naylor <johncnaylorls@gmail.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.

>> Should we add a TAP test for this as well?
>
> I don't see any existing TAP tests for type checks.

Thanks, good to know.

--
Best regards,
Chengpeng Yan




Attachment

pgsql-hackers by date:

Previous
From: Bryan Green
Date:
Subject: [PATCH] Make select_views regression test output deterministic
Next
From: Andrey Borodin
Date:
Subject: Improve cube GiST page splits