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

On Wed, Mar 12, 2025 at 2:20 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Taking a step back after discussing this with some colleagues, I need to
> contradict what I said at the start of this thread. There's a worry
> that changing pg_attribute.attnotnull in the way I initially suggested
> might not be such a great idea after all. I did a quick search using
> codesearch.debian.net for applications reading that column and thinking
> about how they would react to this change; I think in the end it's going
> to be quite disastrous. We would break a vast number of these apps, and
> there are probably countless other apps and frameworks that we would
> also break. Everybody would hate us forever. Upgrading to Postgres 18
> would become as bad an experience as the drastic change of implicit
> casts to text in 8.3. Nothing else in the intervening 17 years strikes
> me as so problematic as this change would be.

I don't agree with this conclusion. The 8.3 casting changes were
problematic because any piece of SQL you'd ever written could have
problems. This change will only break queries that look at the
attnotnull column. While there may be quite a few of those, it can't
possibly be of the same order. I think it's routine that changing the
name or type of system catalog columns breaks things for a few people
(e.g. procpid->pid, or relistemp->relpersistence) and we sometimes get
complaints about that, but at least you can grep for it and it's
mostly going to affect admin tools rather than all the queries
everywhere.

That's not to say that adding a second bool column instead of changing
the existing column's data type is necessarily the wrong way to go.
But I think you're overestimating the blast radius by quite a lot.

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