Tom Lane wrote:
>Dave Cramer <pg@fastcrypt.com> writes:
>
>
>>The official JDBC driver is not being shipped with the project for
>>exactly the same reasons, I fail to see any compelling reason to ship
>>either java PL.
>>
>>
>
>
>
>>Unless we are going to create a complete distribution with a unified
>>build, or at least a way to build each project (which I am in favour
>>of) then we leave the server to itself and all other projects exist
>>separately.
>>
>>
>
>The only argument I find interesting for including the PLs in core
>(which has zilch to do with how any particular packager ships them)
>is that it's easier to do maintenance that way: if we make a change in
>an API that affects the PLs, we can change the PLs at the same time.
>
>
Yes, exactly. And if you look back at the history of, say, plperl.c, you
will find plenty of such instances.
>However, that argument only holds water if the core developers are
>able/willing to make the corresponding changes. And in that light,
>the fact that PL/Java includes a huge whack of non-C code is very
>significant. *I* won't take responsibility for fixing PL/Java when
>I break it, because I don't know Java well enough. I don't know what
>other people who do core development feel about that --- but I dislike
>the idea that when someone changes such an API, the buildfarm will go
>all red because there's only one person with the ability to fix PL/Java.
>
>
>
I take your point. I do have some java-fu, but I don't know how many
other committers do, for example.
The sad truth is that an effort to be absolutely fair and treat everyone
the same may result in some PLs being worse off without any getting
better off. I don't think we should aim at a Pareto disimprovement. Has
it worked well in the case of client libraries? I am not sure it has.
One thing is for sure, we need to do some proselytizing among packagers
to make sure they pick up more than just what is in core.
cheers
andrew