Re: pg_migrator to /contrib in a later 9.0 beta

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_migrator to /contrib in a later 9.0 beta
Дата
Msg-id 24442.1272638755@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_migrator to /contrib in a later 9.0 beta  (Dimitri Fontaine <dfontaine@hi-media.com>)
Ответы Re: pg_migrator to /contrib in a later 9.0 beta
Re: pg_migrator to /contrib in a later 9.0 beta
Re: pg_migrator to /contrib in a later 9.0 beta
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Invalidating dependent views and functions
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: missing file in git repo