Re: OID conflicts

Andrew Dunstan wrote:
> You misunderstood me. I meant he wanted to make use of such a facility,
> not that he wanted to build it.

Yeah, I had enough things on my plate just getting enums to work :)

> By all means float ideas on this - the problem seems to me to be
> ensuring that reservations are time limited, but no doubt Tom Lane and
> Bruce will have opinions ...

OK, one way for such a scheme to work (ie so that patch authors wouldn't
have to worry about OIDs disappearing out from under them) would be to
be able to specify OIDs in a slightly more symbolic form. All the OIDs
allocated for a given patch are likely to be in a block, so you could do
something like (FEATURE_NAME+0), (FEATURENAME+1) or something like that,
rather than hardcoding 2989 or whatever, and hope that the precompiler
could sort it all out. Then you could just have some featureoid.h file
which would define the starting points, and you could just update that
file when someone allocates some oids to point to the latest free one.

I'm don't know whether there are enough patches which allocate OIDs for
it to be worth building such infrastructure, though. It wouldn't just be
the first line in catalog entries, it would have to be all over the
place, e.g. pg_proc has a column whose value in the catalog file is a
string with the oid numbers of the parameters that the function takes. I
suspect, reluctantly, that the pain of patch authors maintaining these
is likely to be less than the pain of hacking the catalog generation
stuff to support something smarter. I'd love to be proven wrong, though.

Hmm. A simpler way lessen the pain might be to have a script which could
update OIDs in your catalog files. You'd have to run it BEFORE doing a
merge. Ie, suppose I've allocated 2978-2991 in my patch, but since then
OIDs have been allocated up to and including 2980. The way to tell that
this is the case would be to do a clean checkout and run the unused_oids
script. Then you could feed the numbers 2978, 2991 and 2980 into the
magical update_oids script which could do a fairly simple sed type of
job on the catalog files. Then you could CVS update and look on in
happiness when duplicate_oids returns nothing and unused_oids show no
gaps. Obviously, being the good patch author that you are, you would
then run your extensive regression tests to make sure that everything is
sweet. :)

If there's interest in such a thing, I might have a go at it. If it
works as described above, would it have a fighting chance of inclusion?
I'd probably use perl rather than pure bourne shell / sed.

Cheers

Tom