Re: pg_migrator to /contrib in a later 9.0 beta - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pg_migrator to /contrib in a later 9.0 beta
Date
Msg-id 4BDAEF71.8090905@dunslane.net
Whole thread Raw
In response to Re: pg_migrator to /contrib in a later 9.0 beta  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_migrator to /contrib in a later 9.0 beta  (Dimitri Fontaine <dfontaine@hi-media.com>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: missing file in git repo
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_migrator to /contrib in a later 9.0 beta