Re: [PG19] Three bugs with a CHECK constraint that only the child enforces

On Sat, Oct 24, 2026 at 12:00 PM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Here is v5. 0001 and 0002 are your v4. 0003 dumps the child's
> ENFORCED CHECK as local when no parent enforces it, as you suggested.
>

V5-0001 looks good to me.

I was just pointing out that there is a precedent for pg_dump restoring a
constraint that has (conislocal = false) as one with (conislocal = true).

I'm less sure this is the right thing to do for regular table inheritance, so
let's see what others think. For partitions, though, I believe this is
what we need to do.

While experimenting, I also noticed that the following code in
src/backend/catalog/heap.c has no equivalent for NOT NULL constraints:

/*
* In case of partitions, an inherited constraint must be inherited
* only once since it cannot have multiple parents and it is never
* considered local.
*/
if (rel->rd_rel->relispartition)
{
con->coninhcount = 1;
con->conislocal = false;
}

If NOT NULL constraints were handled exactly like CHECK constraints in the
code above, the NOT NULL constraint on table ppnn_1 below would end up with
(conislocal = false).

CREATE TABLE public.ppnn (col1 integer) PARTITION BY LIST (col1);
CREATE TABLE public.ppnn_1 (col1 integer CONSTRAINT nn NOT NULL);
ALTER TABLE public.ppnn ATTACH PARTITION public.ppnn_1 FOR VALUES IN (1);
ALTER TABLE public.ppnn ADD CONSTRAINT nn NOT NULL col1 NOT VALID;

Should the NOT NULL constraint on ppnn_1 have conislocal = false?
It's related to pg_constraint.conislocal behavior, so I am posting here too.
----------------------------------------------------------------------------------------------------------------------------------
To summarize where this thread:

v5-0001 is a fix for PG19.

v5-0002 and v5-0003 fix the problem for PG18 as well. However, they
require us to accept that pg_dump may restore a child's inherited CHECK
constraint with pg_constraint.conislocal = true, even though it was false
in the original database.
The visible consequence is that, after a
restore, ALTER TABLE ... DROP CONSTRAINT on the parent no longer drops the
child's copy of the constraint; the child keeps it as a local constraint.
(Given table inheritance is not liked by many people, maybe it's OK to
change conislocal for table inheritance, but not partitioning
inheritance)

--
jian
https://www.enterprisedb.com/