On Fri, Mar 28, 2025 at 2:42 PM Alvaro Herrera <alvhe...@alvh.no-ip.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
