Re: pg_migrator to /contrib in a later 9.0 beta

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_migrator to /contrib in a later 9.0 beta
Date: 2010-05-01 10:49:05
Message-ID: AANLkTilqwZiQ8Hi5YdBYM5k5YritlBVpKCK-9Goh7HRJ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Sat, May 1, 2010 at 02:23, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> Tom Lane wrote:
>>> Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
>>> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>> >> I also think that the standards for contrib should not be so lax that a
>>> >> completely new module can be added after beta.  (This is mostly informed
>>> >> by the feeling that contrib should go away entirely.)
>>>
>>> > +1
>>>
>>> > For the record, the contrib replacement would look like proper Extension
>>> > handling in dump&restore, PGXS support for windows, and PGAN for source
>>> > level archive distribution. We'd still rely on distributions support for
>>> > binaries.
>>>
>>> Both of you are living in some fantasy land.  The reason contrib is held
>>> to a lower standard than core is that nobody is willing to put the same
>>> level of effort into contrib.  There are modules in there (most of them,
>>> in fact) that haven't been touched for years, other than as part of
>>> system-wide search-and-replace patches.  Extension support is not going
>>> to magically fix that and cause maintenance effort to appear from
>>> nowhere.
>>>
>>> In the end, the main useful function that contrib serves is to provide
>>> examples of how to write Postgres extensions.  Because of that, removing
>>> it as Peter suggests doesn't seem like a good idea to me.
>>
>> So what do people want to do with pg_migrator?  I don't think calling
>> pg_migrator a major features requires it to be in /bin.  We added full
>> text search to /contrib years ago and that was a major feature.
>
>
> There is a reason people said that "8.3 comes with full text search" -
> that's when it really  became a major feature to the outside world.
> Before that, it wasn't included in most comparisons. It was a PITA to
> install (well, not install, but upgrading when you had it, etc). (once
> you knew the insides, it was a major feature yes, but people didn't
> know about that)
>
> 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?

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-05-01 12:22:23 Re: standbycheck was:(Re: [HACKERS] testing hot standby
Previous Message Magnus Hagander 2010-05-01 07:32:45 Re: pg_migrator to /contrib in a later 9.0 beta