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
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
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
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
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-complete to
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
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_oids
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
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.
Reserving a range
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
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 script
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
12 matches
Mail list logo
