Andres Freund <and...@anarazel.de> writes:
> On 2019-01-21 18:52:05 -0500, Tom Lane wrote:
>> Yes, I said in so many words that I was proposing increasing
>> FirstNormalObjectId. I do not think the issues with pg_upgrade itself
>> are insoluble --- it would need some historical knowledge about what
>> FirstNormalObjectId had been in each prior version, but that's a pretty
>> minor problem in the big scheme of things.
> Just about every installation uses the oids directly after
> FirstNormalObjectId, so that seems fairly painful.
It would be painful to change the OIDs of objects that pg_upgrade
tries to preserve the OIDs of --- but those are just tables, types,
and roles. Everything else would get renumbered automatically during
pg_upgrade's dump and reload of the schema. The point of my proposal
was that having fixed OIDs for those specific object types might not
be necessary for the use-case of generating new FuncExprs and OpExprs.
(You would need to look up some associated types, but those would not
be hard to get.)
An advantage of the OID-mapping proposal is that it can support getting
the OIDs of tables and types too.
> It'd be more
> realistic to create a new zone at UINT32_MAX - something, but that'd
> likely still conflict in plenty installations (thanks to toast and WITH
> OIDS tables). I'm curious as to how to solve that, if you have a
> sketch - less because of this, and more because I think it's not
> unlikely that we'll encounter the need for this at some point not too
> far away.
I have no idea how we'd move table or type OIDs, given that those are
potentially on-disk. (Actually ... are table OIDs really on-disk
anywhere in user data? Types yes, but tables?)
regards, tom lane
