Re: pg_migrator to /contrib in a later 9.0 beta

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_migrator to /contrib in a later 9.0 beta
Дата
Msg-id 3454.1272728534@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_migrator to /contrib in a later 9.0 beta  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pg_migrator to /contrib in a later 9.0 beta  (Bruce Momjian <bruce@momjian.us>)
Re: pg_migrator to /contrib in a later 9.0 beta  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> A lot of people are not willing to put stuff labeled "contrib" on
>> their production boxes.
>> 
>> And as Tom says, even we *ourselves* acknowledge that things in
>> /contrib are held to a lower standard. If we put that label on
>> pg_migrator, it doesn't exactly signal people that this is something
>> they should use on their critical database.

> Well, I guess that begs the question...  IS this something they should
> use on their critical database?

Not unless it gets some serious testing during the 9.0 beta cycle.
Which it surely won't get if it's not included in the core tarball.

I think that having it in contrib for a release cycle or so would be
exactly the right approach, actually.  Peter's position that it should
be in /bin is fine *once the bugs are out*.  Just dropping it there
doesn't make the bugs go away.
        regards, tom lane


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: standbycheck was:(Re: [HACKERS] testing hot standby
Следующее
От: Tom Lane
Дата:
Сообщение: Protecting against case where shmget says EINVAL instead of EEXIST