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

From Tender Wang
Subject Re: not null constraints, again
Date
Msg-id CAHewXNn5nExR5vm7bRbM55+TME56-pc_yiXdLDtVmOiJ8E1teA@mail.gmail.com
Whole thread Raw
In response to Re: not null constraints, again  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: not null constraints, again
List pgsql-hackers


Alvaro Herrera <alvherre@alvh.no-ip.org> 于2025年4月16日周三 19:24写道:
Here's another version where I do skip searching for children twice, and
rewrote the comments.

I also noticed that in child tables we were only looking for
pg_attribute.attnotnull, and not whether the constraints had been
validated or made inheritable.  This seemed a wasted opportunity, so I
refactored the code to instead examine the pg_constraint row and apply
the same checks as for the constraint on the parent (namely, that it's
valid and not NO INHERIT).  We already check for these things downstream
(alter table phase 2, during AdjustNotNullInheritance), but only after
potentially wasting more work, so it makes sense to do it here (alter
table phase 1) given that it's very easy.  I added some tests for these
things also, as those cases weren't covered.

if (conForm->contype != CONSTRAINT_NOTNULL)
    elog(ERROR, "constraint %u is not a not-null constraint", conForm->oid);
 
I feel that using conForm->conname is more friendly than oid for users.

Others look good for me.

--
Thanks,
Tender Wang

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: pg_dump: Fix dangling pointer in EndCompressorZstd()
Next
From: Alvaro Herrera
Date:
Subject: Re: not null constraints, again