Re: contrib vs. gborg/pgfoundry for replication solutions

Joe Conway wrote:
> 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 backend code is duplicated
> in the external project. It also has no build system of its own.

Both very valid points and together they indicate a decision point ...

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

... which is right here.

Either dblink is vital, important and clean enough to move into the main
backend code, then let's do it. You claim it is vital and important, but
not clean? Then you know what to do.

> [...]
>
> 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.

The driver from my point of view is that some things have been sitting
in contrib for quite some time that are neither maintained, nor wanted
by anyone. Don't take it personal, I just chose dbmirror and dblink
because both fall to some degree into the same usage category as Slony,
and both are active projects (I hate shooting at sitting ducks). If we
can demonstrate that even projects as vital and complex as these two
have a turning point where it says "into the backend or out of contrib",
then things like "noupdate" or "userlock" will have a hard time to show
any reason to make an exception.

>
> Anyway, just my 2cents.
>
> Joe

Cool ... found 2 cents :-)

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #