Re: [HACKERS] An Idea for OID conflicts

2006-09-19 Thread Tom Dunstan
Whoops, I hadn't read this far when I sent the last message on the other thread. Gevik Babakhani wrote: 3. Make a small utility that goes through a patch, finds the new OIDs and changes them back to a value specified by the committer(s). This is effectively what I ended up suggesting in the

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Tom Dunstan
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 "

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Tom Lane
Tom Dunstan <[EMAIL PROTECTED]> writes: > [ some good arguments snipped ] > I like the script idea much better. It wouldn't be bad to even allow > patches to be submitted with OIDs in the high 9000 or whatever range. > The committer responsible for committing the patch could just run the > update

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Tom Dunstan
Gregory Stark wrote: 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. No kidd

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Jim C. Nasby
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 > > 1. This way the new OIDs are easy to recognize and the developer can > > continue the work. > > Reser

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Tom Dunstan
Whoops, I hadn't read this far when I sent the last message on the other thread. Gevik Babakhani wrote: 3. Make a small utility that goes through a patch, finds the new OIDs and changes them back to a value specified by the committer(s). This is effectively what I ended up suggesting in the a

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Neil Conway
On Mon, 2006-09-18 at 14:10 -0400, Andrew Dunstan wrote: > My idea was to have a file called reserved_oids.h which would contain > lines like: > > #error "do not include this file anywhere" > CATALOG(reserved_for_foo_module,9876) /* 2006-09-18 */ > > and which would be examined by the unused_oid

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Tom Lane
Gregory Stark <[EMAIL PROTECTED]> writes: > Those types, functions and operators that aren't used by system tables could > be created by a simple SQL script instead. Only if you don't need to know their OIDs anywhere in the C code. I'm not certain offhand how many of the non-core objects are so r

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Gevik Babakhani
On Mon, 2006-09-18 at 14:36 -0400, Tom Lane wrote: > Gevik Babakhani <[EMAIL PROTECTED]> writes: > > 3. Make a small utility that goes through a patch, finds the new OIDs > > and changes them back to a value specified by the committer(s). > > > Would this be workable? > > That utility sounds AI-c

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Gregory Stark
Gevik Babakhani <[EMAIL PROTECTED]> writes: > 1. When using new OIDs always start from a fixed number. For example > 1. 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

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Tom Lane
Gevik Babakhani <[EMAIL PROTECTED]> writes: > 3. Make a small utility that goes through a patch, finds the new OIDs > and changes them back to a value specified by the committer(s). > Would this be workable? That utility sounds AI-complete to me ... regards, tom lane ---

Re: [HACKERS] An Idea for OID conflicts

2006-09-18 Thread Andrew Dunstan
Gevik Babakhani wrote: Folks, I would like to have your thoughts on a solution for the duplicate OIDs. I wanted to apply the uuid patch on a newly download source from the CVS. Patching and "make install" went just okay but "make check" and initdb failed to my surprise. A quick look at duplicat

[HACKERS] An Idea for OID conflicts

2006-09-18 Thread Gevik Babakhani
Folks, I would like to have your thoughts on a solution for the duplicate OIDs. I wanted to apply the uuid patch on a newly download source from the CVS. Patching and "make install" went just okay but "make check" and initdb failed to my surprise. A quick look at duplicate_oids showed that almost