pg_migrator to /contrib in a later 9.0 beta
in [PgSql]
|
Prev: [HACKERS] pg_migrator to /contrib in a later 9.0 beta
Next: [HACKERS] failed assertion and panic in standby mode
From: Tom Lane on 30 Apr 2010 10:45 Dimitri Fontaine <dfontaine(a)hi-media.com> writes: > Peter Eisentraut <peter_e(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 30 Apr 2010 10:55 Tom Lane wrote: > Dimitri Fontaine <dfontaine(a)hi-media.com> writes: > >> Peter Eisentraut <peter_e(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 30 Apr 2010 11:08 On fre, 2010-04-30 at 10:45 -0400, Tom Lane wrote: > In the end, the main useful function that contrib serves is to provide > examples of how to write Postgres extensions. Maybe, but pg_migrator surely doesn't fit that. And neither does about a third of the other contrib modules, IMO. > Because of that, removing > it as Peter suggests doesn't seem like a good idea to me. contrib means many things to many people, and that's exactly the problem in my mind: It doesn't mean anything in particular. If we were to separate it into - examples - production-quality add-ons with small user base - production-quality add-ons that everyone wants, but we keep them as plugins because plugins are cool - experimental code that we wanted to ship anyway - (historically) differently licensed code then these discussions would be much simpler. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 30 Apr 2010 14:22 Andrew Dunstan <andrew(a)dunslane.net> writes: > Quite so. Getting a better extensions mechanism doesn't mean we should > abandon what we currently have, IMNSHO. Yeah, agreed. Exactly what I proposed. The only change is the distribution mean. Either we keep things as they are now exactly, or we use the new Archive Network facilities, in the spirit of being sure they get exercised, requiring that commiters gets to use them and maybe use a separate code repository for contribs. Or simply an adjusted Makefile. Summary: the only proposed change is how to do it, not what we do. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 30 Apr 2010 20:23
Tom Lane wrote: > Dimitri Fontaine <dfontaine(a)hi-media.com> writes: > > Peter Eisentraut <peter_e(a)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. So what do people want to do with pg_migrator? I don't think calling pg_migrator a major features requires it to be in /bin. We added full text search to /contrib years ago and that was a major feature. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |