Re: not null constraints, again - Mailing list pgsql-hackers

From Tender Wang
Subject Re: not null constraints, again
Date
Msg-id CAHewXN=fZpaOk=PnzKaaZ+gJQSBSoF829C2zLaGfzN_dwmk48g@mail.gmail.com
Whole thread Raw
List pgsql-hackers


Alvaro Herrera <alvherre@alvh.no-ip.org> 于2024年8月31日周六 11:59写道:
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.
 
Thanks for working on this again.

 AT_PASS_OLD_COL_ATTRS, I didn't see any other code that used it. I don't think it's necessary.

I will take the time to look over the attached patch.

--
Tender Wang

pgsql-hackers by date:

Previous
From: Junwang Zhao
Date:
Subject: Re: Partitioned tables and [un]loggedness
Next
From: David Rowley
Date:
Subject: Re: ANALYZE ONLY