Re: An Idea for OID conflicts

Gevik Babakhani <pgdev(at)xs4all(dot)nl> 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