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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
