Re: BUG #19747: pg_dump does not pin array_nulls, so restore mangles NULL array elements - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #19747: pg_dump does not pin array_nulls, so restore mangles NULL array elements
Date
Msg-id 1201948.1791236086@sss.pgh.pa.us
Whole thread
In response to BUG #19747: pg_dump does not pin array_nulls, so restore mangles NULL array elements  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #19747: pg_dump does not pin array_nulls, so restore mangles NULL array elements
List pgsql-bugs
PG Bug reporting form <noreply@postgresql.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



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #19745: tsquery input: 33 nested "!" raise XX000 via elog(), escaping pg_input_is_valid()
Next
From: Tom Lane
Date:
Subject: Re: BUG #19744: contrib/seg output truncates to 6 significant digits, breaking dump/restore