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

From Tom Lane
Subject Re: not null constraints, again
Date
Msg-id 1719550.1744746674@sss.pgh.pa.us
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> 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



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Next
From: Jacob Champion
Date:
Subject: Re: dispchar for oauth_client_secret