Tom Lane wrote: > Dimitri Fontaine <dfonta...@hi-media.com> writes: > > Peter Eisentraut <pete...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
