Re: An Idea for OID conflicts

On Mon, Sep 18, 2006 at 07:46:41PM +0100, Gregory Stark wrote:
> 
> Gevik Babakhani <pgdev@xs4all.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.

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                                    jimn@enterprisedb.com
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)