From: | Tender Wang <tndrwang(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: not null constraints, again |
Date: | 2024-09-03 07:17:33 |
Message-ID: | CAHewXNk+G2XxvJX6S31QecihWymMFeL1X0j+GiESFH2NPaBeHw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.
>
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.
--
Thanks,
Tender Wang
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2024-09-03 07:21:23 | Re: per backend I/O statistics |
Previous Message | Kyotaro Horiguchi | 2024-09-03 07:07:58 | Re: per backend I/O statistics |