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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq