Message-ID: <568DA841.3060509@anastigmatix.net>
Date: Wed, 06 Jan 2016 18:50:25 -0500
From: Chapman Flack <chap@anastigmatix.net>
MIME-Version: 1.0
References: <568D9AD2.6000402@hogranch.com> <568D9D41.5010807@hogranch.com>
 <568D9F06.70107@hogranch.com>
In-Reply-To: <568D9F06.70107@hogranch.com>
Subject: Re: [Pljava-dev] huh...
Content-Type: text/plain; charset="us-ascii"

On 01/06/16 18:11, John R Pierce wrote:

> EG, instead of JDBC class methods, SQLJ was a preprocessor, similar to
> Pro*C/ECPG.

Exactly. Kind of a cool idea, they've got some sample app code up
on oracle.com, and there's an old tutorial on the wayback machine:

https://docs.oracle.com/cd/A91202_01/901_doc/java.901/a90212/sampapps.htm#1005043

http://web.archive.org/web/20030530081254/http://www.sqlj.org/tutorials/sqlj-sigmod/index.htm

They made a reference implementation way back in 1998, based on a
parser for Java 1.1, and they released it public-domain to encourage
adoption by multiple vendors, which did in fact happen:

http://web.archive.org/web/20030621161812/http://www.sqlj.org/implement.htm

It included a Java preprocessor, which would translate your program to
an equivalent one that depended on a runtime library (classes in
the sqlj.runtime package, which are also in the reference implementation).
For code that was released public domain, it's remarkably scarce on the net,
but I did find a tarball back in November.

The sqlj.runtime package could be implemented on top of jdbc, in which
case you could run your translated program as a remote client, or it
could be implemented in the server and you could run your code there.

There were three pieces in total: "SQLJ part 0" was the preprocessed,
embedded SQL/Java, which became ISO/IEC 9075-10 Object Language Bindings
(SQL/OLB).

"SQLJ part 1" was "Java methods as SQL procedures" and "SQLJ part 2"
was "Java classes as SQL types", and both of those pieces got combined
as ISO/IEC 9075-13 Java Routines and Types (SQL/JRT) which is what
PL/Java (partially) implements. SQL/OLB and SQL/JRT are pretty cleanly
separated parts of the SQL standard, except there is a couple obscure
mentions of the sqlj.runtime package in the text for SQL/JRT. For
example, a method returning setof composite type would be allowed to
return an sqlj.runtime.ResultSetIterator, and in addition to the
Java property sqlj.defaultconnection defined to "jdbc:default:connection"
(which PL/Java does supply), there is also supposed to be a property
sqlj.runtime giving the name of a class implementing
sqlj.runtime.RuntimeContext. That appears in SQL/JRT with no explanation
whatever and was baffling until I dug up the SQL/OLB info.

So the term SQLJ has referred both to things PL/Java is and things
PL/Java isn't, and it's not completely obvious how to read that
Oracle announcement, but the way I am reading it is that they will
drop the support for preprocessed "SQLJ part 0" programs server-side,
but will still allow you to use them over JDBC, and they probably
aren't dropping support for part 1&2, SQL/JRT, PL/Java-like stuff.

-Chap
_______________________________________________
Pljava-dev mailing list
Pljava-dev@lists.pgfoundry.org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev