Re: contrib vs. gborg/pgfoundry for replication solutions - Mailing list pgsql-hackers

Marc G. Fournier wrote:
> Why is it the core developers responsibility to make sure that an
> application stays in sync with the main tree?  Personally, that is giving
> life to software that could just as easily be unused by anyone, but kept
> in the code base because "a commit was made to it less then 6 months ago"
> ...

Well, in the case of dblink, consider this:

- It is used by a fair number of people -- questions are answered on the  lists at least once a week with "see
contrib/dblink".

- It is dependent on backend code to the extent that it cannot be built  outside of the contrib folder, unless some
backendcode is duplicated  in the external project. It also has no build system of its own.
 

- dblink-type capability should someday make it into the backend, albeit  in the form of something compliant to the
SQL/MEDspec. This is  standard functionality in many of the RDBMSs that Postgres users  migrate from, and it is needed
byenterprise users.
 

- The maintenance burden on core developers is pretty minimal. Recent  examples of where it was touched due to other
changesin the backend  are:
 
     * Tom - sort_mem to work_mem change     * me - elog to ereport change     * Neil - change to tuplestore_begin_heap
declaration
   These changes were part of the routine "grep for all the affected   code for the change I'm making", hence almost
free(at least in my   opinion, I'll let Tom or Neil object if they feel otherwise).
 

Had dblink been on gborg, they (Tom and Neil) never would have seen that 
their backend change affected it. It might have been weeks or months 
before anyone noticed that it no longer worked against cvs tip (possibly 
during beta for the next release). At that point the effort involved in 
figuring out why it no longer works, while not huge, is certainly not as 
small as the change-as-you-go approach we have now. I deal with this 
very issue for PL/R. I have to pay close attention to commit messages or 
I get bitten.

These same arguments apply to other things in contrib, and probably 
could apply to some that currently are not.

In any case, I don't understand what the driver is to kill contrib. I 
fully agree that it should be maintained (meaning that someone other 
than core is interested enough to provide patches if non-trivial 
maintenance is required to keep it compiling), and stuff that is not 
used or suitably licensed should be removed. The contrib build system 
ought to be maintained in working order in any case because it makes it 
far easier to extend Postgres with your own functions.

Anyway, just my 2cents.

Joe