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 по дате отправления: