Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
Date
Msg-id CA+TgmobacrNZkDchjrHtkgth4xjd=rDX04OPSWBHDhCQAtQ71g@mail.gmail.com
Whole thread Raw
In response to Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Wed, Apr 2, 2025 at 5:17 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> I don't quite love this behavior, but since there have been no
> complaints, I suppose it's okay and we should just do the same for
> not-nulls.

I don't understand the issue. It seems like the pg_dump output shown
here would recreate the catalog state.

> FWIW the part that I think you're not right on, is that constraints on
> partitioned tables never have local definitions.  Even if you start with
> a constraint defined locally in the partition, the ATTACH operation will
> change its conislocal flag to false.  So you can never "drop" it from
> the partition.  For regular inheritance, we don't flip the conislocal
> flag to false, but you're still prevented from "dropping" the constraint
> from the child while the inheritance relationship exists (i.e. you can
> never set conislocal=false in such a case).

Hmm. I think this is different from attislocal/attinhcount.

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



pgsql-hackers by date:

Previous
From: Alena Rybakina
Date:
Subject: Re: Replace IN VALUES with ANY in WHERE clauses during optimization
Next
From: Jakub Wartak
Date:
Subject: Re: Draft for basic NUMA observability