From: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18405: flaw in dump of inherited/dropped constraints |
Date: | 2024-03-25 16:16:11 |
Message-ID: | 866537D5-2EF9-4559-B4C6-AF16191A0D9E@elevated-dev.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> thanks to Alvaro's work to treat NOT NULL the same way we've long
> treated more general CHECK constraints. So there's no need to do
> anything in v17, and I think changing the behavior in released
> branches would draw more complaints than plaudits. (Also, if pg_dump
> did try harder to duplicate this situation, the result would likely be
> that the dump would fail to load into v17+.)
I'd call that an acceptable resolution. My main concern is dump/restore not being able to dump & restore an existing database, and this v17 change fixes this case. (For background, this odd inheritance wasn't a deliberate design, it was a (supposedly temporary) workaround for a client bug.)
>> ... So it looks like prior to 16, plain dumps had this
>> problem, but custom format dumps did not.
>
> Given the way pg_dump works, that's pretty hard to believe: you
> should get bitwise the same result from pg_dump to text versus
> pg_dump -Fc | pg_restore. Can you provide a self-contained test
> showing a case where it doesn't?
I will re-run tests when I get a bit of time--it is possible I confused versions or schemas somewhere along the line of switching back and forth.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-03-25 16:17:25 | Re: BUG #18407: ALTER TABLE SET SCHEMA on foreign table with SERIAL column does not move sequence to new schema |
Previous Message | Tom Lane | 2024-03-25 16:11:09 | Re: BUG #18405: flaw in dump of inherited/dropped constraints |