Re: pg_migrator to /contrib in a later 9.0 beta

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_migrator to /contrib in a later 9.0 beta
Date: 2010-04-30 14:45:55
Message-ID: 24442.1272638755@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2010-04-30 14:52:35 Re: missing file in git repo
Previous Message Tom Lane 2010-04-30 14:38:19 Re: Invalidating dependent views and functions