Re: pl/Ruby, deprecating plPython and Core

Поиск
Список
Период
Сортировка
От Thomas Hallgren
Тема Re: pl/Ruby, deprecating plPython and Core
Дата
Msg-id 4302EFB5.2020102@mailblocks.com
обсуждение исходный текст
Ответ на Re: pl/Ruby, deprecating plPython and Core  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: pl/Ruby, deprecating plPython and Core
Следующее
От: Marko Kreen
Дата:
Сообщение: Re: pl/Ruby, deprecating plPython and Core