Horton

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

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Álvaro Herrera <alvherre@alvh.no-ip.org>
To: "jian he" <jian.universality@gmail.com>, "Rushabh Lathia" <rushabh.lathia@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-04-06T04:56:30Z
Lists: pgsql-hackers 
Hi

I've been giving this some final polish which have me time to think it through, and I think Peter is right. We should not be adding the new column, but instead RelationBuildTupleDesc should use its existing scan of pg_constraint to determine validity status of constraints. We may need in addition a further value for attnullability that means unknown, "a constraint exists but we don't know yet if it's valid or invalid" for the times when we scanned pg_attribute but not yet pg_constraint. I think it's not too large a patch on top of that we have.

I'm going on a little excursion now but should be back to work on this in a couple of hours.

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