Tom Lane wrote:
> The scary thing about a script is the assumption that it will make all
> and only the changes needed. Four-digit magic numbers are not that
> uncommon in C code. I think it might be safer if we made the arbitrary
> OID range for an uncommitted patch be large, say eight digits (maybe
> "12345xxx"). The script would knock these down to 4-digit numbers,
> ie removing one tab stop, so it wouldn't be too hard on your formatting.
> Given the current OID generation mechanism, the presence of large OIDs
> in the initial catalogs shouldn't be a problem for testing patches,
> even assuming that the OID counter gets that high in your test database.
Well, the only files that a script would touch would be in
src/include/catalog, since any other reference to them should be through
a #define anyway IMO. And I figured that the 9000 range was as good a
magic number as any, at least in that directory. The nice thing about
9000 numbers is that they're still under the 10000 magic starting point
for initdb, so you're guaranteed not to run into that range when
inserting data while testing your patch. I'm a little shady on how OID
uniqueness works though, so maybe it's not a problem. Are OIDs
guaranteed to be unique across a whole cluster, or just in a given
relation (including wraparound scenarios)?
The other point about the script scariness is that obviously you'd have
to a) pass make check including whatever tests test out your patch (and
there should be some if you've added a new proc or type or whatever),
and b) the patch would have to survive review, where OID weirdness
should leap out when the patch is viewed stripped of all the surrounding
catalog noise. Maybe. :)
Anyway if having OIDs up above 10000 isn't a problem, then it doesn't
really matter either way, so having them stand out by being longer seems
just as good to me as my suggestion.
Thanks
Tom
