Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints

On Fri, Mar 28, 2025 at 2:42 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Maybe the real problem here is that making the (valid) child constraint
> no longer local when the parent constraint is not valid is not sensible,
> precisely because pg_dump won't be able to produce good output. That
> sounds more workable to me ... except that we'd have to ensure that
> validating the parent constraint would turn the child constraints as not
> local anymore, which might be a bit weird. But maybe not weirder than
> the other approach.

It seems like a bad idea to make conislocal and coninhcount have
anything to do with whether the constraint is valid. We need those to
mean what they have traditionally meant just to make the correct
things happen when the constraint is dropped, either directly from the
child or at some ancestor of that child. If something is dropped at an
ancestor table, we cascade down the tree and decrement coninhcount. If
something is dropped at a child table, we can set conislocal=false.
The constraint goes away, IIUC, when coninhcount=0 and
conislocal=false, which directly corresponds to "this constraint no
longer has a remaining definition either locally or by inheritance". I
don't see how you can change much of anything here without breaking
the existing structure. Validity could have separate tracking of some
sort, possibly as elaborate as convalidlocal and convalidinhcount, but
I don't think it can get away with redefining the tracking that we
already have for existence.

--
Robert Haas
EDB: http://www.enterprisedb.com