| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | kehan5800(at)gmail(dot)com |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19747: pg_dump does not pin array_nulls, so restore mangles NULL array elements |
| Date: | 2026-10-05 21:34:46 |
| Message-ID: | 1201948.1791236086@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> pg_dump writes a null array element as the unquoted word NULL. Whether the
> array input function reads that as a null depends on array_nulls, which is
> PGC_USERSET and can be persisted with ALTER DATABASE/ROLE ... SET. The
> dump's preamble (_doSetFixedOutputState(), src/bin/pg_dump/
> pg_backup_archiver.c:3431) pins the other input-side settings
> (client_encoding, standard_conforming_strings, check_function_bodies,
> xmloption, row_security, ...) but not array_nulls, so the restoring session
> inherits the target database's value.
Meh. TBH, that GUC was past its shelf life ten years ago. What
I'd rather do about this report is just summarily remove the GUC.
If we make pg_dump issue a SET for it then we'll never be able
to remove it.
We could alternatively do what we've done with some other GUCs
whose time has passed: force them to have constant values and
accept SET commands only when the value matches. But I doubt
that this one ever got widespread enough use to justify doing that
much work. I'd rather just nuke it from orbit.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-10-05 21:52:49 | Re: BUG #19744: contrib/seg output truncates to 6 significant digits, breaking dump/restore |
| Previous Message | Tom Lane | 2026-10-05 19:02:02 | Re: BUG #19745: tsquery input: 33 nested "!" raise XX000 via elog(), escaping pg_input_is_valid() |