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
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
"
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
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
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
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
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
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
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
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
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 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
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
13 matches
Mail list logo