Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: jian he <jian.universality@gmail.com>, Rushabh Lathia <rushabh.lathia@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-02T14:40:38Z
Lists: 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

Commits

  1. Allow NOT NULL constraints to be added as NOT VALID

  2. Add missing deparsing of [NO] IDENT to XMLSERIALIZE()

  3. backend launchers void * arguments for binary data

  4. Add pg_constraint rows for not-null constraints

  5. Create the infrastructure for planner support functions.

  6. Add prokind column, replacing proisagg and proiswindow