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:29:20Z
Lists: pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes: > On Fri, Feb 8, 2019 at 10:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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. > I imagined that the machine-readable catalog data would allow us to > assign non-numeric identifiers to this OID range. Perhaps there'd be a > textual symbol with a number in the range of 0-20 at the end. Those > would stick out like a sore thumb, making it highly unlikely that > anybody would forget about it at the last minute. Um. That would not be just an add-on script but something that genbki.pl would have to accept. I'm not excited about that; it would complicate what's already complex, and if it works enough for test purposes then it wouldn't really stop a committer who wasn't paying attention from committing the patch un-revised. To the extent that this works at all, OIDs in the 9000 range ought to be enough of a flag already, I think. 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