On Tue, Sep 28, 2010 at 11:14 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Yeah, I guess that's true. > 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 ;-) Maybe so, but the more steps there are that have to be manually remembered, the harder it gets. Run the regression tests, check for duplicate OIDs, bump catversion, bump WAL version, bump pg_dump archive version, bump pg_control version, check for unnecessary header includes, audit trailing whitespace, look for leftovers that don't need to be committed. If we can combine a step or two, it just makes life easier. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
