| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-07 06:54:34 |
| Message-ID: | 0d93fce2149eb3512ce665f2706e25a410751c95.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, 2026-10-06 at 16:06 -0400, Tom Lane wrote:
> I wrote:
> > PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > > [misbehavior with array_nulls on]
>
> > 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.
>
> Concretely, about like this. (BTW, another argument for doing
> this rather than fixing pg_dump is that there are a ton of other
> applications that will likely misbehave if array_nulls is turned
> on underneath them.)
+1
I have never seen this used in the field. One less potential headache!
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rahul | 2026-10-07 09:14:21 | Re: BUG #19733: Row not visible to a new snapshot after its transactional logical decoding message has been streamed |
| Previous Message | Etsuro Fujita | 2026-10-07 05:00:41 | Re: BUG #19698: IMPORT FOREIGN SCHEMA treats a NOT VALID NOT NULL constraint as validated |