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

On Fri, Mar 21, 2025 at 2:04 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> In several of the cases that I checked, the application just tests the
> returned value for boolean truth. If we change the column from boolean
> to char, they would stop working properly because both the 't' and the
> 'f' char values would test as true. But suppose we were to rename the
> column; that would cause developers to have to examine the code to
> determine how to react. That might even be good, because we're end up
> in a situation were no application uses outdated assumptions about
> nullness in a column.

Yes.

> However, consider the rationale given in
> https://postgr.es/m/2542644.1733418030@sss.pgh.pa.us
> that removing attndims would break PHP -- after that discussion, we
> decided against removing the column, even though it's completely
> useless, because we don't want to break PHP. You know, removing
> attnotnull would break PHP in exactly the same way, or maybe in some
> worse way. I don't see how can we reach a different conclusion for this
> change that for that one.

Well, that discussion seems awfully weird to me. I can recall plenty
of cases where we've changed stuff in the system catalog and rebuffed
complaints from people who were grumpy about having to adjust their
queries. I don't really understand what makes that case different.

I mean, maybe there's an argument that some changes are more
disruptive than others. For instance, if removing attndims would force
drivers to run extra more complicated queries to learn whether a
certain type is an array type, one could argue that taking it away
without providing some alternative is breaking the drivers in some
fundamental way. I'm not sure whether that's a real problem, but there
is no such argument to be made here. There's no proposal on the table
to entirely remove any information from pg_attribute -- only to turn
something that is presently two-valued into something three-valued.
So, it will still be possible for it to learn the same facts that it
can learn today, it will just perhaps need to be adjusted in terms of
exactly how it does that. But if that is prohibited then what made it
OK all the other times we've done it?

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. Also, relpersistence is an example of a
seemingly very similar kind of change - turning a Boolean column into
a char column so it can support three values. Do we with the benefit
of hindsight consider that to have been a mistake? I don't, because I
think that PostgreSQL development will be paralyzed if we prohibit
such changes, but opinions might vary.

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