Martijn van Oosterhout wrote:
Seems awfully complicated. The numbers don't mean anything, they don't
have to be contiguous. If you want to reduce the chance of conflict,
find a nice big block in unused_oids, add a random number between 0 and
100 and use that. Or squeeze yourself into a block that exactly fits
what you need. There's simply not that many patches that need numbers
to worry about anything complicated.
When I needed a few dozen OIDs for an (unapplied) patch I simply picked
2900 and went up from there. That was a while ago and there's no
conflict yet.
Well, since there were no gaps for a significant way up to the last used
OID (I forget where the last gap was), I figured that there was a no-gap
policy. If that's not the case, then indeed, writing a script might be
overkill.
OTOH, I would think that the last allocated OID will continue to rise,
and eventually your patch will have a conflict. Or alternately it'll get
applied before then, and someone else will have to worry about whether
the gap between the end of the contiguous OIDs and where your patch
starts allocating them is enough for their needs, or whether they should
stake out some other part of the reserved OID space for themselves. And
of course, someone else might submit a patch in the meantime that uses
OIDs in the gap or stakes out the same space. Any of the above cases,
having a tool to remap the OIDs might be useful.
I suppose the main point is that given the hardcoded nature of OIDs used
in the catalogs, allocating them is not a process that lends itself to
parallel development. An easy way to remap OIDs in a patch sidesteps a
bunch of issues.
Cheers
Tom
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
