Re: pg_migrator to /contrib in a later 9.0 beta - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_migrator to /contrib in a later 9.0 beta
Date
Msg-id 3454.1272728534@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_migrator to /contrib in a later 9.0 beta  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_migrator to /contrib in a later 9.0 beta
Re: pg_migrator to /contrib in a later 9.0 beta
List 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 by date:

Previous
From: Simon Riggs
Date:
Subject: Re: standbycheck was:(Re: [HACKERS] testing hot standby
Next
From: Tom Lane
Date:
Subject: Protecting against case where shmget says EINVAL instead of EEXIST