[Pljava-dev] I remembered why we might want bytecode scalar types

Bear Giles wrote:

> CREATE FUNCTION get_colors() RETURNS SETOF varchar AS $$
> BEGIN
> List<String> colors = Arrays.asList("red", "green", "blue");
> return colors;
> END $$
> LANGUAGE JAVA;

I'll see your in-situ Java code, and raise you JSR-223. If we stick to
Java 6 and up, there's already the machinery to support a bunch of
dynamic scripting languages right out of the box, and one of them,
for that matter, JavaScript, is already /in/ the box.

If we add a piece that allows 'CREATE LANGUAGE foo ...' using a
generic javax.script invocation handler and whatever script-engine jars
have been put on the path, then PL/Java suddenly becomes PL/polyglot
for not much work, and that could be pretty neat.

DO LANGUAGE 'javascript' $$
...
$$;

I saw a blog post with some javascript examples using jdbc directly,
or using the authors' own library, jOOQ:

http://blog.jooq.org/2014/06/06/java-8-friday-javascript-goes-sql-with-nashorn-and-jooq/

(The examples are for a normal client connection and don't illustrate
anything you'd feel especially compelled to move to the backend, but
they give the flavor of the thing.)

With a lot of scripting languages more tailored to expressing some
quick idea in a few lines, they might have a wider audience than
CREATE FUNCTION LANGUAGE 'java' with the code inline. (Also, I know
Thomas put a high priority on following the SQL/JRT standard, which
does the jar thing.)

On the other hand, if we had JSR-223, I wonder how easily you could
write your "language inlinejava" and drop it in as a jar as another
scripting language. (We might want to permit some javax.script extension
for persisting compilation artifacts like class files. A 'validator'
handler for the language could expire them when a new CREATE FUNCTION
is done.) I like the way you autogenerate the Java declarations based
on the SQL types. Sort of the exact complement of how the DDR
generator now writes you the SQL part based on the Java types. Then
you'd have your choice of which half of the work you'd rather not do. :)

I need more head-wrapping around the security policy considerations
before anybody should expect a pull request....

-Chap