PG Bug reporting form <noreply@postgresql.org> writes:
> Create the following schema:
> create table t1 (c boolean not null);
> create table t2 (c boolean) inherits (t1);
> alter table t2 alter c drop not null;
> ...
> The drop of the not null constraint is not reflected in the dump. Thus
> playing back the dump results in column c of table t2 having the not null
> constraint.
I'm not super excited about doing anything about that in the
back branches. It's fundamentally bogus that we allowed the
DROP NOT NULL in the first place, because this structure
allows a SELECT from t1 to see null values of c, which is
pretty inconsistent. As of HEAD, we don't allow it any more:
regression=# create table t1 (c boolean not null);
CREATE TABLE
regression=# create table t2 (c boolean) inherits (t1);
NOTICE: merging column "c" with inherited definition
CREATE TABLE
regression=# alter table t2 alter c drop not null;
ERROR: cannot drop inherited constraint "t1_c_not_null" of relation "t2"
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+.)
> ... 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?
> One more thing, making the custom format dump using pg_dump 14, then
> restoring with pg_restore 16, gets the erroneous not null
> constraint.
Hmmm ... maybe using a different pg_restore version would affect
this. But mostly pg_restore just emits what it finds in the dump
file, unless you told it to filter things. I tried dumping a
situation like this in a v14 database using various pg_dump and
pg_restore versions, and they all produced the same table
definitions.
regards, tom lane
