Re: Should we automatically run duplicate_oids?
От | Bruce Momjian |
---|---|
Тема | Re: Should we automatically run duplicate_oids? |
Дата | |
Msg-id | 20130802050045.GB4174@momjian.us обсуждение исходный текст |
Ответ на | Should we automatically run duplicate_oids? (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Should we automatically run duplicate_oids?
|
Список | pgsql-hackers |
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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Вложения
В списке pgsql-hackers по дате отправления: