On Fri, Mar 21, 2025 at 2:04 PM Alvaro Herrera <alvhe...@alvh.no-ip.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.1733418...@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
