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 attached patch adds List *nnconstraints, which store the not-null definition, in struct CreateStmt.
This makes me a little confused about List *constraints in struct CreateStmt. Actually, the List constraints
store ckeck constraint, and it will be better if the comments can reflect that. Re-naming it to List *ckconstraints
seems more reasonable. But a lot of codes that use stmt->constraints will be changed.
Since AddRelationNewConstraints() can now add not-null column constraint, the comments about AddRelationNewConstraints()
should tweak a little.
"All entries in newColDefaults will be processed. Entries in newConstraints
will be processed only if they are CONSTR_CHECK type."
Now, the type of new constraints may be not-null constraints.
If the column has already had one not-null constraint, and we add same not-null constraint again.
Then the code will call AdjustNotNullInheritance1() in AddRelationNewConstraints(). The comments
before entering AdjustNotNullInheritance1() in AddRelationNewConstraints() look confusing to me.
Because constraint is not inherited.
--
