Re: Should we automatically run duplicate_oids?

Sent from my iPad

On 02-Aug-2013, at 10:30, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Mon, Jul 8, 2013 at 06:25:44PM -0700, Peter Geoghegan wrote:
>> When rebasing a patch that I'm working on, I occasionally forget to
>> update the oid of any pg_proc.h entries I may have created. Of course
>> this isn't a real problem; when I go to initdb, I immediately
>> recognize what has happened. All the same, it seems like there is a
>> case to be made for having this run automatically at build time, and
>> having the build fail on the basis of there being a duplicate - this
>> is something that fails reliably, but only when someone has added
>> another pg_proc.h entry, and only when that other person happened to
>> choose an oid in a range of free-in-git-tip oids that I myself
>> fancied.
>>
>> Sure, I ought to remember to check this anyway, but it seems
>> preferable to make this process more mechanical. I can point to commit
>> 55c1687a as a kind of precedent, where the process of running
>> check_keywords.pl was made to run automatically any time gram.c is
>> rebuilt. Granted, that's a more subtle problem than the one I'm
>> proposing to solve, but I still see this as a modest improvement.
>
> FYI, attached is the pgtest script I always run before I do a commit;
> it also calls src/tools/pgtest. It has saved me from erroneous commits
> many times.
>
+1,a much needed thing.Duplicate oids is a pain enough to deserve its own solution.

Regards,

Atri