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 24442.1272638755@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_migrator to /contrib in a later 9.0 beta  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: pg_migrator to /contrib in a later 9.0 beta  (Andrew Dunstan <andrew@dunslane.net>)
Re: pg_migrator to /contrib in a later 9.0 beta  (Peter Eisentraut <peter_e@gmx.net>)
Re: pg_migrator to /contrib in a later 9.0 beta  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Dimitri Fontaine <dfontaine@hi-media.com> writes:
> Peter Eisentraut <peter_e@gmx.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Invalidating dependent views and functions
Next
From: Andrew Dunstan
Date:
Subject: Re: missing file in git repo