John Naylor <john.nay...@2ndquadrant.com> writes: >> On 2/8/19, Tom Lane <t...@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 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