Re: Should we automatically run duplicate_oids?
| От | Atri Sharma |
|---|---|
| Тема | Re: Should we automatically run duplicate_oids? |
| Дата | |
| Msg-id | A3D533B5-4D72-470D-BAFF-4E124A6EF33A@gmail.com обсуждение исходный текст |
| Ответ на | Re: Should we automatically run duplicate_oids? (Bruce Momjian <bruce@momjian.us>) |
| Список | pgsql-hackers |
Sent from my iPad On 02-Aug-2013, at 10:30, Bruce Momjian <bruce@momjian.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
В списке pgsql-hackers по дате отправления: