Peter Eisentraut <peter_e@gmx.net> writes:
> Marc G. Fournier wrote:
>> That is the plan ... unless someone knows a reason why they can't be
>> built independently of the core?
> How about this one: Everything we have moved from the core to gborg so
> far has been a miserable failure.
JDBC seems to be doing fine ... but I think that exception just proves
your point. If there's not a viable community around a particular piece
of code, pushing it out to gborg/pgFoundry won't magically create one.
I strongly disagree with moving out the existing PLs; it's just a whole
lot easier to maintain them alongside the backend. (This is especially
true of plpgsql of course, but it is very common that global edits hit
the other PLs as well.) I think Joe Conway's experience with
maintaining plR separately shows the overhead involved.
I would like to see plperlNG eventually supplant the existing plperl in
core CVS. If it weren't for the circular-build-dependency issue, I'd
probably be in favor of pulling in plPHP too.
I do see a point to having pgFoundry though, which is that it allows
more people to be granted direct commit access to the bits of code they
are working on. For the core project, I think we should continue the
present policy of keeping commit access pretty closely held, so pulling
all that stuff back in would make the committers a real bottleneck.
With separate projects we can let each project determine its own commit
access policies.
I agree with the opinion that we need to figure out how to produce
more-or-less-integrated release filesets from multiple projects.
There's too much stuff being pushed out for development or release
engineering reasons that users want to see as part of the standard
product. We've let the lure of "separate projects can have separate
release schedules" blind us to the fact that for most projects there's
not really any benefit there. Client-side libraries like JDBC can
get some benefit, but server-side stuff I don't think so.
regards, tom lane
