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

From Alvaro Herrera
Subject Re: not null constraints, again
Date
Msg-id 202504152110.gr3ga55h55q6@alvherre.pgsql
Whole thread Raw
In response to Re: not null constraints, again  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: not null constraints, again
List pgsql-hackers
On 2025-Apr-15, Tom Lane wrote:

> +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.

Right.

> 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.

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
> on me.

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)



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Align memory context level numbering in pg_log_backend_memory_contexts()
Next
From: Tom Lane
Date:
Subject: Re: not null constraints, again