Should we automatically run duplicate_oids?

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Should we automatically run duplicate_oids?
Дата
Msg-id CAM3SWZQqtHJxnhwKT2W7dnQVDLH-xYrqbubW09RbhsNjcRweOA@mail.gmail.com
обсуждение исходный текст
Ответы Re: Should we automatically run duplicate_oids?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Should we automatically run duplicate_oids?  (Atri Sharma <atri.jiit@gmail.com>)
Re: Should we automatically run duplicate_oids?  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
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.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: [9.4 CF] Free VMs for Reviewers & Testers
Следующее
От: James Sewell
Дата:
Сообщение: Re: [PATCH] Add an ldapoption to disable chasing LDAP referrals