On Thu, Oct 12, 2023 at 10:35 AM Tom Lane <tgl@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