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. This would make it a whole lot more practical to define all those smallfoo data types we were discussing too with all the cross-data-type comparison operators as well. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
