Re: An Idea for OID conflicts

Whoops, I hadn't read this far when I sent the last message on the other
thread.

> Gevik Babakhani wrote:
>> 3. Make a small utility that goes through a patch, finds the new OIDs
>> and changes them back to a value specified by the committer(s).

This is effectively what I ended up suggesting in the aforementioned
post. There's no reason that the OIDs would have to start at 10000,
though, and that would probably necessitate a change in what I
understand is the policy of starting a db cluster at OID 10000. OTOH,
while waiting for patch acceptance, there's probably benefit in using
OIDs well above the current first free OID: you don't have to repeatedly
run the script. If you started at 9000, say, you'd only have to run the
update script when you were about to submit the patch. If you're right
on the line, you'd have to run it every week or whatever.

>> Would this be workable?

Well, *I* think so, with the suggestions made above.

Andrew Dunstan wrote:
> My idea was to have a file called reserved_oids.h which would contain
> lines like:
>
> #error "do not include this file anywhere"
> CATALOG(reserved_for_foo_module,9876) /* 2006-09-18 */
>
> and which would be examined by the unused_oids script.
>
> To get oids reserved, a committer would add lines to that file for you.
> When your patch was done, it would include stuff to remove those lines
> from the file.
>
> That way you will be working with the oids your patch will eventually
> use - no later fixup necessary.

This sounds like a recipe for gaps in the OID list to me. If the patch
gets rejected / dropped, you've got a gap. If the user doesn't use all
the allocated OIDs, you've got a gap. What happens if the patch author
decides that they need more OIDs? More time from a committer to reserve
some. Plus it has the downside that the author has to ask for some to be
reserved up front, they need to have a very good idea of how many
they'll need, and a committer has to agree with them. If you'd asked me
how many I thought I'd need when I started the enum patch, I would have
told you a number much smaller than the number that I ended up using. :)

Of course, if you don't care about gaps, then half of the objections
above go away, and the other half can be solved by reserving more than
you'd need. Given the fairly contiguous nature of OIDs in the catalogs
currently, it would appear that we do care about gaps, though.

I like the script idea much better. It wouldn't be bad to even allow
patches to be submitted with OIDs in the high 9000 or whatever range.
The committer responsible for committing the patch could just run the
update script before comitting the code.

Cheers

Tom