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.
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@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com