Re: An Idea for OID conflicts - Mailing list pgsql-hackers

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