Re: pl/Ruby, deprecating plPython and Core

Josh Berkus wrote:
> People:
>
> How about we draft some criteria for inclusion of a PL in the main distro?
>
> Suggestions:
>
> 1) The PL must be "stable" (that is, not capable of crashing the backend)
Check. (well, a more humble statement is perhaps to say that any bug
that would cause a crash would be considered critical and get immediate
attention. Shit happens).

> 2) The PL must be buildable only using --with-{lang} and createlang
> (assuming that the user has the correct libraries)
PL/Java builds using the pgx stuff and needs no further config then an
environment setting that appoints the JVM. Adding a --with-java is
probably very easy once the code is included in the distro (I say
probably because I have no idea of how to do it).

> 3) There must be a regression test included, which tests both creating the
> lang and creating+executing a small function in it.
PL/Java includes a bunch of tests today. I guess you have some test
harness where such tests can be plugged in?

> 4) The PL must have at least one maintainer who subscribes to
> pgsql-hackers.
Check. And if more people wants to step in then I'm all for it.

> 5) It must be possible to build the PL without changing the licensing of
> PostgreSQL (this excludes PL/R, unfortunately).
Check.

>
> Controversial Criterion:
> 6) The PL should be buildable in "trusted" mode. (I vote no on this one)
Check. PL/Java always enables two language handlers, java and javaU.
Nevertheless, my vote would also be to exclude this criteria. The
important thing is that the user of an untrusted PL knows the implications.

I'd like to add one other criteria that PL/Java is lacking today but I
think every PL should have.
7) The PL language handler(s) must be created with an associated
VALIDATOR function.

> I, myself, do not think that either popularity or inclusion of the language
> in Linux distros should be a criterion. If PL/Haskell or PL/Smalltalk
> catches on with *our* community it should be good enough for us. Heck,
> were it not for the licensing and build issues, I'd be advocating strongly
> fro PL/R.
>
I agree. Even if Java is very popular in general it is less so within
this community and that is what counts. A criterion that I think would
be valid though (and also likely relate to popularity) is of course if a
sponsor made a commitment and secured the continued evolution and
maintenance of the PL.

There's also another point that has not been brought up yet. Most PL's
use code that's inlined in the SQL function body. Java (like C) cannot
do that. So there are two categories of PL's; the ones that allow inline
code and the ones that require modules that contain the code to be
loaded somehow. PL/Java belongs to the latter. Not everyone is in favor
of that approach.

Regards,
Thomas Hallgren