Hello
Here I present another attempt at making not-null constraints be
catalogued. This is largely based on the code reverted at 9ce04b50e120,
except that we now have a not-null constraint automatically created for
every column of a primary key, and such constraint cannot be removed
while the PK exists. Thanks to this, a lot of rather ugly code is gone,
both in pg_dump and in backend -- in particular the handling of NO
INHERIT, which was needed for pg_dump.
Noteworthy psql difference: because there are now even more not-null
constraints than before, the \d+ display would be far too noisy if we
just let it grow. So here I've made it omit any constraints that
underlie the primary key. This should be OK since you can't do much
with those constraints while the PK is still there. If you drop the PK,
the next \d+ will show those constraints.
One thing that regretfully I haven't yet had time for, is paring down
the original test code: a lot of it is verifying the old semantics,
particularly for NO INHERIT constraints, which had grown ugly special
cases. It now mostly raises errors; or the tests are simply redundant.
I'm going to remove that stuff as soon as I'm back on my normal work
timezone.
sepgsql is untested.
I'm adding this to the September commitfest.
The test case in constraints.sql, as below:
CREATE TABLE notnull_tbl1 (a INTEGER NOT NULL NOT NULL);
^^^^^^^^^^
There are two not-null definitions, and is the second one redundant?
When we drop the column not-null constraint, we will enter ATExecDropNotNull().
Then, it calls findNotNullConstraint() to get the constraint tuple. We already have
attnum before the call findNotNullConstraint(). Can we directly call findNotNullConstraintAttnum()?
In RemoveConstraintById(), I see below comments:
"For not-null and primary key constraints,
obtain the list of columns affected, so that we can reset their
attnotnull flags below."
However, there are no related codes that reflect the above comments.
--
