public inbox for [email protected]
help / color / mirror / Atom feedFrom: Chapman Flack <[email protected]>
Subject: Re: [Pljava-dev] huh...
Date: Wed, 06 Jan 2016 18:50:25 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
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
[email protected]
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
view thread (5+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected]
Subject: Re: [Pljava-dev] huh...
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox