Robert Haas <robertmh...@gmail.com> writes:
> Another angle on this problem is that, at least AFAICT, the duplicate
> OIDs are completely harmless so long as they are in different
> catalogs. And if they are in the same catalog, then initdb will fail
> (and shame on you if you don't notice that). Long, long ago
> pg_description was indexed just by object-OID, so duplicates would be
> a problem, but that hasn't been the case since 2001, and I'm not aware
> of anything else that relies on OIDs being globally unique either. So
> maybe we should decide that we just don't care about this any more.
No, we shouldn't. The reason we still have the policy of global
uniqueness of manually-assigned OIDs is that those OIDs frequently
need to be copied in multiple places (eg, operators may need to be
entered in pg_amop). It gets a lot easier to make mistakes, and
harder to check for mistakes, if the OIDs aren't unique.
The duplicate_oids script is just something that committers are supposed
to know to run when applying a patch that messes with the catalogs.
That's a sufficiently small minority of patches that I don't see the
attraction of trying to wire it into every build, nor every regression
test. Maybe the landscape is changing to the point where we can't trust
committers to get this right, but I haven't seen evidence of that. You
certainly won't forget it again soon ;-)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
