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. -- marko ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
