Subject: Re: not null constraints, again

From: Tom Lane <[email-masked]>
Date: Tue, 15 Apr 2025 15:51:14 -0400

Alvaro Herrera <[email-masked]> writes:
> However, I've also been looking at this and realized that this code can
> have different structure which may allows us to skip the
> find_inheritance_children() altogether.  The reason is that we already
> scan the parent's list of columns searching for not-null constraints on
> each of them; we only need to run this verification on children for
> columns where there is none in the parent, and then only in the case
> where recursion is turned off.

+1.  Fundamentally the problem here is that pg_restore needs

ALTER TABLE ONLY foo ADD PRIMARY KEY

to not recurse to child tables at all.  It is expecting this command
to acquire a lock on foo and nothing else; and it has already taken
care of making foo's PK column(s) NOT NULL, so there is no reason we
should have to examine the children.

Looking at the patch itself, it doesn't seem like the got_children
flag is accomplishing anything; I guess that was leftover from an
earlier version?  You could declare "List *children" inside the
block where it's used, too.  Basically, this patch is just moving
the check-the-children logic from one place to another.

Also I find the comments still a bit confusing, but maybe that's
on me.

			regards, tom lane

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 15 Apr 2025 23:10:26 +0200

> should have to examine the children.

Right.

> the check-the-children logic from one place to another.

Ah yes, I forgot to set got_children when reading the children list.
This happens within the loop for columns, so the idea is to obtain that
list just once instead of once per column.  I don't think there's any
ill effect from doing it multiple times, but it's wasted work and that's
what led me to adding got_children.  I'll add the assignment.

> Also I find the comments still a bit confusing, but maybe that's

I'll review tomorrow morning, maybe I can find some improvements for
them.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"La conclusión que podemos sacar de esos estudios es que
no podemos sacar ninguna conclusión de ellos" (Tanenbaum)