Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
Date
Msg-id CA+TgmoYV3fKfKMg07aP7fm97i3xmG7OA7MUDOZeHPAJsZ2B8-g@mail.gmail.com
Whole thread Raw
In response to Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Mon, Mar 24, 2025 at 12:29 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > Again, I'm not 100% positive that changing the Boolean column to a
> > three-valued column is the right way forward, but it does have the
> > advantage of saving a byte, and the width of system catalog tables has
> > been a periodic concern.
>
> In this case, as I already said, the new boolean column would go in
> what's currently padding space, so there's no widening taking place.

IMHO, there will almost certainly be more single-byte columns at some
point in the future, so I feel like using up padding space is not much
different than actual widening over the long term.

> Please don't think that I'm in favor of doing it the difficult way for
> no reason.  Previous versions of the patch (changing attnotnull to
> char), from the Postgres core code perspective, were pretty much ready
> -- we're having this discussion only to avoid the breakage.  I could
> save us a bunch of time here and just push those patches, but I think
> the responsible thing here (the one we're less likely to regret) is not
> to.

Fair enough. I think I've said what I want to say, and I'm not here to
substitute my judgement for yours.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: vacuum_truncate configuration parameter and isset_offset
Next
From: Nathan Bossart
Date:
Subject: Re: vacuum_truncate configuration parameter and isset_offset