Re: BUG #19747: pg_dump does not pin array_nulls, so restore mangles NULL array elements

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

In response to

Browse pgsql-bugs by date

  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()