Re: Why don't we have a small reserved OID range for patch revisions?
John Naylor <john.naylor@2ndquadrant.com>
From: John Naylor <john.naylor@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@bowt.ie>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-14T16:01:35Z
Lists: pgsql-hackers
Attachments
- v1-reassign-high-oids.patch (text/x-patch) patch v1
I wrote: > On 2/8/19, 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. > > This might be something that can be done inside reformat_dat_files.pl. > It's a little outside it's scope, but better than the alternatives. Along those lines, here's a draft patch to do just that. It handles array type oids as well. Run it like this: perl reformat_dat_file.pl --map-from 9000 --map-to 2000 *.dat There is some attempt at documentation. So far it doesn't map by default, but that could be changed if we agreed on the convention of 9000 or whatever. -- John Naylor https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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