running-java-within-postgres comment

Hi!

Thanks for the blog post about PL/Java. I noticed a couple of things that might allow it to be simplified.

1. While your post says PL/Java is not available as a prebuilt package, as you are using debian in your example, in fact it is. If you enable the PostgreSQL debian repository, you can simply apt-get install postgresql-server-9.6 postgresql-9.6-pljava (along with whatever other packages you need at run time). There is then no need for maven, gcc, git, or any build-from-source process.
2. The debian package of PL/Java declares its own dependency on default-java, so that package will be pulled in if you don’t have it, without needing to be requested.
3. When using the debian package, there is no need for SET pljava.libjvm_location as the packager has compiled in a default value that refers to the normal default-java package. Therefore, the pljava.libjvm_location variable only needs to be set if you wish to run PL/Java with a different Java runtime than the default.
4. If the user postgres is a superuser in your database, there is no real need for GRANT USAGE ON LANGUAGE java TO postgres;.
5. It might be worth mentioning that the jdbc:default:connection is not a conventional JDBC connection (it does not use PG’s network protocol to converse with the backend); it is simply a shim that presents direct internal access to the backend via the familiar JDBC API.
6. Code written for Java 7 or later would conventionally use try-with-resources when opening JDBC Connections, Statements, or ResultSets. (In PL/Java, for Connection it doesn’t really matter, as that shim “connection” never closes anyway. But it is harmless, and for Statement or ResultSet it can ensure resources are released.)
7. If a @Function annotation does not have a comment attribute, but the function has a javadoc comment, the first sentence of the javadoc will be used as the SQL function comment.

But those are minor points. I think the post did quite a good job covering the basics.

A couple more direct links into the documentation that might be helpful are to the Hello, world example (which is much like your own example but has a “further reading” list at the bottom) and, for production environments, the VM option recommendations page: Java’s default VM options on a server machine kind of assume it has the machine to itself, and some tweaks to those options can greatly reduce its footprint when running in PostgreSQL.

Thanks for the coverage!

[jcflack]

You’re welcome. 😃 I noticed another thing:

   SELECT sqlj.install_jar( 'file:///tmp/simple-java-function/target/simple-java-function.jar','jfunctions', true );

The function takes the fully-qualified path of the .jar file, …

To be honest, PL/Java doesn’t really care whether the URL is relative or absolute, certainly not enough to put “fully-qualified” in boldface.

select sqlj.install_jar('file:foo.jar', 'foo', false);

would load foo.jar if it happened to be in the server’s current directory (the datadir). If you give a relative file: URL, you just have to know where the file is, relative to the datadir.

You can also give an absolute file: URL using just one leading slash rather than three. Three slashes are just the //hostname/path form where the hostname happens to be empty, meaning the local host, just the same as /path.

Cheers!

[jcflack]

I see another possible refinement: 😃

GRANT USAGE ON LANGUAGE java TO your_user;

… the GRANT USAGE statement is required for your database application user to have access to pljava.

A user with USAGE privilege on a language is able to create new functions that are written in that language.

Once a function is created, any user with EXECUTE privilege on that function is able to use the function.

Depending on your security requirements, you might want the same user to be able to create new functions and to use existing ones, or you might want an application user only to be able to execute existing functions, while reserving the privilege of creating functions to a different user, or even only to superusers (in which case no GRANT USAGE is needed).