On Thu, Oct 12, 2023 at 10:35 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > You have the burden of proof backwards. That would add a great deal > of new mechanism, and you haven't provided even one reason why it'd > be worth doing.
"A great deal of new mechanism" seems like a slight exaggeration. We preserve a bunch of kinds of OIDs already, and it wouldn't be any harder to preserve this one than the ones we preserve already, or so I think. So it would be some additional mechanism, but maybe not a great deal. As to whether it's a good idea, it isn't necessary for the system to operate properly, so we didn't, but it's a judgement call whether it's better for other reasons, like being able to have regprocedure columns survive an upgrade, or making users being less confused, or allowing people supporting PostgreSQL having an easier time debugging issues. Personally, I've never been quite sure we made the right decision there. I admit that I'm not particularly keen to try to add the amount of mechanism that would be required to preserve every single OID everywhere, but I also somehow feel like the fact that we don't is pretty weird. The pg_upgrade experience right now is a bit as if you woke up in the morning and found that city officials came by during the night and renumbered your house, thus changing your address. Then, they sent change of address forms to everyone who ever mails you anything, plus updated your address with your doctor's office and your children's school. In a way, there's no problem: nothing has really changed for you in any way that matters. Yet, I think that would feel pretty uncomfortable if it actually happened to you, and I think the pg_upgrade experience is uncomfortable in the same way. -- Robert Haas EDB: http://www.enterprisedb.com
