Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> 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
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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not