Re: Use CompactAttribute more often, when possible - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: Use CompactAttribute more often, when possible
Date
Msg-id 202510200858.wty2i4v763uu@alvherre.pgsql
Whole thread Raw
In response to Use CompactAttribute more often, when possible  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On 2025-Oct-20, David Rowley wrote:

> There's also some more
> complexity around CompactAttribute.attnotnull that's crept in. I think
> I roughly understand the need for that, but the intent of
> CompactAttribute mirroring commonly used pg_attribute fields is made
> no longer true by those changes as it now contains extra information
> that's unavailable in pg_attribute. It'd be nice if pg_attribute also
> had the various additional states of attnotnull that CompactAttribute
> now has. </rant>

Making CompactAttribute not match attnotnull exactly was a quite
deliberate decision, and thoroughly explained in the thread that led to
that development.  Feel free to propose changing attnotnull to match
what we have in CompactAttribute, but 1. I don't think it serves any
purpose, 2. it'd probably be complicated(*) and 3. it might be quite an
uphill battle, as the breakage you'd cause to external software looking
at attnotnull is going to be enormous.

(*) Actually it might not be all that complicated, as I think the
patches submitted by Rushabh at some point implemented the various
states directly in pg_attribute, mirroring what appears in
pg_constraint.

It's possible, of course, to argue that pg_attribute.attnotnull is just
an implementation detail and that client applications shouldn't be
looking at that or that they should be prepared to handle breakage.  We
already had that discussion and I think the prevailing conclusion was
that it's a little bit too entrenched in too many ancient apps and
frameworks, and for too long a time for that to work.  I didn't want
having to revert my not-null constraints patch because of it.

Anyway it's always been the case that certain features are subverted/
modified/evolved in ways that the original author didn't envision.
That's not a bug of the development process, I think, but rather one of
its best features.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"The saddest aspect of life right now is that science gathers knowledge faster
 than society gathers wisdom."  (Isaac Asimov)



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: How can end users know the cause of LR slot sync delays?
Next
From: Jakub Wartak
Date:
Subject: Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)