Re: contrib vs. gborg/pgfoundry for replication solutions

On Wed, 21 Apr 2004, Jan Wieck wrote:

> Joe Conway wrote:
>
> > Jan Wieck wrote:
> >> Taking into account that quite a few people have repeatedly stated that
> >> the components in contrib are considered more supported/recommended than
> >> similar solutions found on gborg or any other external site, I suggest
> >> we move the projects dbmirror and dblink to gborg. The rserv contrib
> >> module seems to me to be an early Perl prototype of erserver, nobody is
> >> working on any more. I suggest we drop that entirely.
> >>
> >> Comments/alternatives?
> >
> > dblink gets regularly updated as and when things change which affect it
> > in the backend. It is more tightly bond to the backend than a client
> > application, which the replication solutions you mention are. It is not
> > a replication solution anyway, so I'm not sure why you would categorize
> > in that way.
>
> None of the replication solutions I see are client applications only.
> Substantial parts of erserver and Slony for example are loadable modules
> and stored procedures, tightly bond to the backend by using data and
> functionality not available via the SPI. So the same problems apply
> here, which then would be a reason to add them to contrib as well?

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"
...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664