public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alvaro Herrera <[email protected]>
To: Rushabh Lathia <[email protected]>
Cc: jian he <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
Date: Thu, 20 Mar 2025 11:26:26 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAGPqQf1x2xMG2d19bqyFDEPTni7h=8T-Gi+_oLRGGGAMzy9tZQ@mail.gmail.com>
Hello
On 2025-Mar-20, Rushabh Lathia wrote:
> Attached is another version of the patch (WIP), where I have
> introduced a new catalog column, pg_attribute.attinvalidnotnull
> (boolean). This column will default to FALSE but will be set to TRUE
> when an INVALID NOT NULL constraint is created. With this approach,
> we can avoid performing extra scans on the catalog table to identify
> INVALID NOT NULL constraints, ensuring there is no performance impact.
I find this a reasonable way forward. We won't impact any applications
that are currently relying on the boolean semantics of attnotnull, while
still allowing the backend to know the real status of the constraint
without having to scan pg_constraint for it.
I also checked the struct layout, which is currently
struct FormData_pg_attribute {
Oid attrelid; /* 0 4 */
NameData attname; /* 4 64 */
/* --- cacheline 1 boundary (64 bytes) was 4 bytes ago --- */
Oid atttypid; /* 68 4 */
int16 attlen; /* 72 2 */
int16 attnum; /* 74 2 */
int32 atttypmod; /* 76 4 */
int16 attndims; /* 80 2 */
_Bool attbyval; /* 82 1 */
char attalign; /* 83 1 */
char attstorage; /* 84 1 */
char attcompression; /* 85 1 */
_Bool attnotnull; /* 86 1 */
_Bool atthasdef; /* 87 1 */
_Bool atthasmissing; /* 88 1 */
char attidentity; /* 89 1 */
char attgenerated; /* 90 1 */
_Bool attisdropped; /* 91 1 */
_Bool attislocal; /* 92 1 */
/* XXX 1 byte hole, try to pack */
int16 attinhcount; /* 94 2 */
Oid attcollation; /* 96 4 */
/* size: 100, cachelines: 2, members: 20 */
/* sum members: 99, holes: 1, sum holes: 1 */
/* last cacheline: 36 bytes */
};
Since there's a one-byte hole after the lot of bools/chars, the new bool
will use it and this won't enlarge the storage, neither in memory nor on
disk.
I have not reviewed this patch in detail yet.
Thank you!
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
view thread (44+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox