On 2025-Mar-21, Robert Haas wrote:
> I don't agree with this conclusion.
Uhm.
> The 8.3 casting changes were problematic because any piece of SQL
> you'd ever written could have problems.
Okay, this much I agree with.
> 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.
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. 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.
> 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.
I am just going by some truth established by previous discussion.
If we agree to remove attnotnull or to change the way it works, then we
can also remove attndims.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
