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.



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to