| From: | Chengpeng Yan <chengpeng_yan(at)outlook(dot)com> |
|---|---|
| To: | John Naylor <johncnaylorls(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: arrays over initdb-created types are broken after pg_upgrade |
| Date: | 2026-08-11 06:34:12 |
| Message-ID: | BB860562-8922-490D-91D9-BAB43CAAE668@outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
> On Aug 11, 2026, at 13:35, John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
>
> 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.
I initially thought that a custom variable-length type could use
`array_in`/`array_out` while setting `ELEMENT` to
`information_schema.sql_identifier`, without being its associated array.
I had overlooked that user-defined types are not allowed to use
`array_subscript_handler` directly.
I agree that "AND e.typarray = t.oid" is a reasonable criterion here.
LGTM.
--
Best regards,
Chengpeng Yan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | solai v | 2026-08-11 06:40:31 | Re: postgres_fdw: Emit message when batch_size is reduced |
| Previous Message | Álvaro Herrera | 2026-08-11 06:32:15 | Re: Crash issue in PG18.5 regression |