On Wed, 31 Jul 2024 at 12:35, Tom Lane <t...@sss.pgh.pa.us> wrote: > Perhaps you can make an argument that nobody would be depending > on that column, but I fear that's wishful thinking. Or maybe you > can argue that any query using it is already broken --- but I > think that's only true if someone tries to do the specific sort > of recursive traversal that you illustrated.
It's true that people could be using it, I certainly don't dispute that. It's just we don't have any rule that we can't do this sort of thing. Take f66e8bf87, for example. It removed relhaspkey from pg_class. It's true that doing that did upset at least one person [1], but our response to that complaint was to reiterate that the example query was broken. I feel the bar is a bit lower for pg_backend_memory_contexts as it was only added in v14, so it's not been around as long as pg_class had been around in 2018 when we removed relhaspkey. My concern here is that the longer we leave the parent column in, the higher the bar gets to remove it. That's why I feel like it is worth considering this now. One thing we could do is remove it and see if anyone complains. If we did that today, there's about a year-long window for people to complain where we could still reverse the decision. Now is probably the best time where we can consider this so I'd be sad if this discussion ended on "someone might be using it.". David [1] https://postgr.es/m/CANu8Fiy2RZL+uVnnrzaCTJxMgcKBDOnAR7bDx3n0P=kycbs...@mail.gmail.com