From: chap at anastigmatix.net (Chapman Flack) Date: Sun, 20 Sep 2015 09:33:26 -0400 Subject: [Pljava-dev] I remembered why we might want bytecode scalar types In-Reply-To: References: Message-ID: <55FEB5A6.90200@anastigmatix.net> Bear Giles wrote: > CREATE FUNCTION get_colors() RETURNS SETOF varchar AS $$ > BEGIN > List 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