From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | |
Subject: | Re: [Pljava-dev] huh... |
Date: | 2016-01-06 23:50:25 |
Message-ID: | 568DA841.3060509@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | PostgreSQL : PostgreSQL 메일 링리스트 : 2016-01-06 이후 토토 사이트 추천 |
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(at)lists(dot)pgfoundry(dot)org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2016-01-07 00:03:32 | Re: [Pljava-dev] huh... |
Previous Message | John R Pierce | 2016-01-06 23:11:02 | Re: [Pljava-dev] huh... |