Tom Lane wrote:
>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.
>
>
Amen. plperlNG was always intended as a replacement.
In fact, one of the reasons I'm a bit sad about us rushing to feature
freeze on 1 June is that Joshua and I had hoped to get a greatly beefed
up plperl ready in time for 7.5, but I don't think we can make June 1.
>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.
>
Indeed. One of the great uses of pgfoundry is as a community site that
can be used for things intended for eventual inclusion in the core but
not yet ready for it.
>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.
>
>
It's a timing thing. When plperlng is ready we will present a largish
patch or set of patches. At that time the separate project would shut
down and plperl would once again be maintained as part of the core.
cheers
andrew
