Re: OID conflicts

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