On Mon, Sep 18, 2006 at 07:46:41PM +0100, Gregory Stark wrote: > > Gevik Babakhani <[EMAIL PROTECTED]> writes: > > > 1. When using new OIDs always start from a fixed number. For example > > 10000. This way the new OIDs are easy to recognize and the developer can > > continue the work. > > Reserving a range of OIDs for experimentation seems like a good idea since it > means nobody's development tree would ever be broken by a cvs update. At least > not because their OIDs were pulled out from under them. > > But I had another thought. It seems like a lot of the catalog include files > don't really need to be defined so laboriously. Just because types and > operators are in the core doesn't mean they need to be boostrapped using fixed > OIDs and C code. > > Those types, functions and operators that aren't used by system tables could > be created by a simple SQL script instead. It's a hell of a lot easier to > write a CREATE OPERATOR CLASS call than to get all the OIDs in in four > different include files to line up properly.
If there's 4 different files involved ISTM it'd be best to have a script that generates those 4 files from a master list. This is something I should be able to create if there's interest. Though I do agree that moving things to SQL where possible probably makes the most sense... -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
