Re: not null constraints, again

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jian he <jian(dot)universality(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: not null constraints, again
Date: 2025-04-16 12:11:45
Message-ID: CAHewXNn5nExR5vm7bRbM55+TME56-pc_yiXdLDtVmOiJ8E1teA@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> 于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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2025-04-16 12:24:18 Re: not null constraints, again
Previous Message Ashutosh Bapat 2025-04-16 11:48:35 Re: pg_dump: Fix dangling pointer in EndCompressorZstd()