From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Should we automatically run duplicate_oids? |
Date: | 2013-07-09 04:40:46 |
Message-ID: | CAOeZVicGmVc5cpX2FqTJhs2bWEuppF7PEPyuL0ZmRArfywWGvQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 9, 2013 at 6:55 AM, Peter Geoghegan <pg(at)heroku(dot)com> 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.
I completely agree with the idea. Doing these checks early in the
build chain would be much more helpful than seeing the logs when
initdb fails.
Regards,
Atri
--
Regards,
Atri
l'apprenant
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Farina | 2013-07-09 05:49:26 | Re: [9.4 CF] Free VMs for Reviewers & Testers |
Previous Message | Craig Ringer | 2013-07-09 04:32:41 | Re: Should we automatically run duplicate_oids? |