Re: BUG #18405: flaw in dump of inherited/dropped constraints
От | Scott Ribe |
---|---|
Тема | Re: BUG #18405: flaw in dump of inherited/dropped constraints |
Дата | |
Msg-id | 866537D5-2EF9-4559-B4C6-AF16191A0D9E@elevated-dev.com обсуждение исходный текст |
Ответ на | Re: BUG #18405: flaw in dump of inherited/dropped constraints (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 switchingback and forth.
В списке pgsql-bugs по дате отправления: