Re: Why don't we have a small reserved OID range for patch revisions?

John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> writes:
>> On 2/8/19, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

I took a quick look at this. I went ahead and pushed the parts that
were just code cleanup in reformat_dat_file.pl, since that seemed
pretty uncontroversial. As far as the rest of it goes:

* I'm really not terribly happy with sticking this functionality into
reformat_dat_file.pl. First, there's an issue of discoverability:
it's not obvious that a script named that way would have such an
ability. Second, it clutters the script in a way that seems to me
to hinder its usefulness as a basis for one-off hacks. So I'd really
rather have a separate script named something like "renumber_oids.pl",
even if there's a good deal of code duplication between it and
reformat_dat_file.pl.

* In my vision of what this might be good for, I think it's important
that it be possible to specify a range of input OIDs to renumber, not
just "everything above N". I agree the output range only needs a
starting OID.

BTW, I changed the CF entry's target back to v12; I don't see a
reason not to get this done this month, and indeed kind of wish
it was available right now ;-)

regards, tom lane