On 10/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > If it doesn't need to be in core, in certainly has zero need to be in
> > contrib and can push to pgFoundry.
> One advantage of having it in contrib is buildfarm testing, as indeed we
> already found out ... although it's true that *keeping* it there now
> that it passes probably won't teach us too much more.
> But I think the argument that was being made was mostly that the Slony
> and Skytools projects would find it easier to depend on a contrib module
> than on something that has to be fetched separately from pgfoundry.
> Now they could work around that by including copies of the pgfoundry
> project in their own distributions, but then they have a collision
> problem if someone tries to install both together.  (I have no idea how
> likely that is, though; it might not be a big problem in practice?)

Well, if it is kicked from /contrib now, one way we could handle
it is by shipping the same module inside both skytools/slony.

That has obvious conflict problems.

Unfortunately the problem has very easy fix - each one keeps
using it's current module.  Very easy, no work required.

But that also scratches the common API possibility.


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to