Re: Why don't we have a small reserved OID range for patch revisions?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-08T18:14:15Z
Lists: pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes: > Why don't we provide a small reserved OID range that can be used by > patch authors temporarily, with the expectation that they'll be > replaced by "real" OIDs at the point the patch gets committed? This > would be similar the situation with catversion bumps -- we don't > expect patches that will eventually need them to have them. Quite a few people have used OIDs up around 8000 or 9000 for this purpose; I doubt we need a formally reserved range for it. The main problem with doing it is the hazard that the patch'll get committed just like that, suddenly breaking things for everyone else doing likewise. (I would argue, in fact, that the reason we have any preassigned OIDs above perhaps 6000 is that exactly this has happened before.) A script such as you suggest might be a good way to reduce the temptation to get lazy at the last minute. Now that the catalog data is pretty machine-readable, I suspect it wouldn't be very hard --- though I'm not volunteering either. I'm envisioning something simple like "renumber all OIDs in range mmmm-nnnn into range xxxx-yyyy", perhaps with the ability to skip any already-used OIDs in the target range. regards, tom lane
Commits
-
Remove remaining hard-wired OID references in the initial catalog data.
- 3aa0395d4ed3 12.0 landed
-
Create a script that can renumber manually-assigned OIDs.
- a6417078c414 12.0 landed
-
Minor improvements for reformat_dat_file.pl.
- 27aaf6eff49a 12.0 landed