Re: pg_migrator to /contrib in a later 9.0 beta
От | Andrew Dunstan |
---|---|
Тема | Re: pg_migrator to /contrib in a later 9.0 beta |
Дата | |
Msg-id | 4BDAEF71.8090905@dunslane.net обсуждение исходный текст |
Ответ на | Re: pg_migrator to /contrib in a later 9.0 beta (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_migrator to /contrib in a later 9.0 beta
|
Список | pgsql-hackers |
Tom Lane wrote: > 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. > > Quite so. Getting a better extensions mechanism doesn't mean we should abandon what we currently have, IMNSHO. cheers andrew
В списке pgsql-hackers по дате отправления: