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
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 |