Re: Use CompactAttribute more often, when possible

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Use CompactAttribute more often, when possible
Date: 2025-10-20 09:13:09
Message-ID: 202510200858.wty2i4v763uu@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2025-10-20 09:18:45 Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)
Previous Message Hayato Kuroda (Fujitsu) 2025-10-20 08:57:32 RE: How can end users know the cause of LR slot sync delays?