Horton

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

Peter Eisentraut <peter@eisentraut.org>

View thread View on postgr.es
From: Peter Eisentraut <peter@eisentraut.org>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: jian he <jian.universality@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Rushabh Lathia <rushabh.lathia@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-03T15:03:34Z
Lists: pgsql-hackers 
On 03.04.25 10:07, Alvaro Herrera wrote:
> The new flag is there for quick access by get_relation_info.  We could
> easily not have it otherwise, because clients don't need it, but its
> lack would probably make planning measurably slower because it'd have to
> do syscache access for every single not-null constraint to figure out if
> it's valid or not.

In the v6 patch, you are adding a attnullability field to the 
CompactAttribute in the tuple descriptor and use that in 
get_relation_info().  That seems like the right approach, because then 
you're doing all that preprocessing about which constraint is active in 
the relcache.  So I don't see where the extra pg_attribute field 
attnotnullvalid is getting used.

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