Thread: PL/java
Hi,
I am the lead architect in a small firm that develops a very specialised ETL platform.
Traditionally, we have used Oracle and PL-SQL, and we are now porting everything to Postgres.
All of our code outside of the database is java and I wiash that all of our code within the database to be also in java.
The PL/java “add-on” is not supported directly by Postgres.
I would like to ask if there is a plan to include it as an official procedural language. If so, when?
Thanks,
—
Zé Rui Marques
On 12/7/20 3:25 AM, Zé Rui Marques wrote: > Hi, > > I am the lead architect in a small firm that develops a very specialised > ETL platform. > > Traditionally, we have used Oracle and PL-SQL, and we are now porting > everything to Postgres. > > All of our code outside of the database is java and I wiash that all of > our code within the database to be also in java. > > The PL/java “add-on” is not supported directly by Postgres. > > I would like to ask if there is a plan to include it as an official > procedural language. If so, when? None that I have heard of. Even if the decision where to made today it would likely a couple of years before it would be included, so that is not going to help you. What is your concern? > > Thanks, > *—* > *Zé Rui Marques* > > -- Adrian Klaver adrian.klaver@aklaver.com
I want to say this. I never liked any extension language. It's like Java is not meant to interact with databases. Nor is python (in my opinion). I think you should skip the search
On Mon, Dec 7, 2020 at 8:15 PM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 12/7/20 3:25 AM, Zé Rui Marques wrote:
> Hi,
>
> I am the lead architect in a small firm that develops a very specialised
> ETL platform.
>
> Traditionally, we have used Oracle and PL-SQL, and we are now porting
> everything to Postgres.
>
> All of our code outside of the database is java and I wiash that all of
> our code within the database to be also in java.
>
> The PL/java “add-on” is not supported directly by Postgres.
>
> I would like to ask if there is a plan to include it as an official
> procedural language. If so, when?
None that I have heard of. Even if the decision where to made today it
would likely a couple of years before it would be included, so that is
not going to help you. What is your concern?
>
> Thanks,
> *—*
> *Zé Rui Marques*
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com
On 12/7/20 7:18 AM, Hemil Ruparel wrote: > I want to say this. I never liked any extension language. It's like Java > is not meant to interact with databases. The JDBC folks might disagree. Nor is python (in my opinion). > I think you should skip the search > > On Mon, Dec 7, 2020 at 8:15 PM Adrian Klaver <adrian.klaver@aklaver.com > <mailto:adrian.klaver@aklaver.com>> wrote: > > On 12/7/20 3:25 AM, Zé Rui Marques wrote: > > Hi, > > > > I am the lead architect in a small firm that develops a very > specialised > > ETL platform. > > > > Traditionally, we have used Oracle and PL-SQL, and we are now > porting > > everything to Postgres. > > > > All of our code outside of the database is java and I wiash that > all of > > our code within the database to be also in java. > > > > The PL/java “add-on” is not supported directly by Postgres. > > > > I would like to ask if there is a plan to include it as an official > > procedural language. If so, when? > > None that I have heard of. Even if the decision where to made today it > would likely a couple of years before it would be included, so that is > not going to help you. What is your concern? > > > > > Thanks, > > *—* > > *Zé Rui Marques* > > > > > > > -- > Adrian Klaver > adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com> > > -- Adrian Klaver adrian.klaver@aklaver.com
On 12/7/20 8:25 AM, Adrian Klaver wrote: > On 12/7/20 7:18 AM, Hemil Ruparel wrote: >> I want to say this. I never liked any extension language. It's like >> Java is not meant to interact with databases. > > The JDBC folks might disagree. > That interaction is strictly sql to db, data to app. As it should be.
On 12/7/20 8:16 AM, Rob Sargent wrote: > > On 12/7/20 8:25 AM, Adrian Klaver wrote: >> On 12/7/20 7:18 AM, Hemil Ruparel wrote: >>> I want to say this. I never liked any extension language. It's like >>> Java is not meant to interact with databases. >> >> The JDBC folks might disagree. >> > That interaction is strictly sql to db, data to app. As it should be. Playing Devil's advocate. It is still Java interacting with a database. The objection I gather is to having Java embedded in the database. SQL interaction is no panacea: https://portswigger.net/daily-swig/sql-injection -- Adrian Klaver adrian.klaver@aklaver.com
The PL/java “add-on” is not supported directly by Postgres.
With a few exceptions (Perl, Python) this is how the community handles all "add-ons". A great number of features available to you are available as third party extensions and not part of core. Zombodb, Timescale and Citus are good examples.
In short, don't worry about whether or not it is "official".
JD
I would like to ask if there is a plan to include it as an official procedural language. If so, when?Thanks,—Zé Rui Marques
Nota Bene:
Almost all official interfaces to/from Oracle are coded in Java
FWIK google's implementations are 95% python
(although you would need to understand JSON formatting for import/export requirements)
for those reasons i tread lightly before disparaging either language
Going Forward:
try to implement PL/SQL that rob/joshua mentioned
if you're calling no-joy after implementing PL/SQL
then we can take a look at interfacing to Postgres ETL binaries with a JNI interface
provided the JNI is spot on with signatures for each referenced function
Almost all official interfaces to/from Oracle are coded in Java
FWIK google's implementations are 95% python
(although you would need to understand JSON formatting for import/export requirements)
for those reasons i tread lightly before disparaging either language
Going Forward:
try to implement PL/SQL that rob/joshua mentioned
if you're calling no-joy after implementing PL/SQL
then we can take a look at interfacing to Postgres ETL binaries with a JNI interface
provided the JNI is spot on with signatures for each referenced function
Un Saludo
m
From: Rob Sargent <robjsargent@gmail.com>
Sent: Monday, December 7, 2020 11:16 AM
To: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Subject: Re: PL/java
Sent: Monday, December 7, 2020 11:16 AM
To: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Subject: Re: PL/java
On 12/7/20 8:25 AM, Adrian Klaver wrote:
> On 12/7/20 7:18 AM, Hemil Ruparel wrote:
>> I want to say this. I never liked any extension language. It's like
>> Java is not meant to interact with databases.
>
> The JDBC folks might disagree.
>
That interaction is strictly sql to db, data to app. As it should be.
On 12/7/20 3:10 PM, Martin Gainty wrote:
If I'm tracking correctly I can say the java implementation of CopyManager is, to me, blindingly fast. So if the E and the T are in java then certainly the L can be also. I have not compared it to straight file-base copy because my data is conceived in Java and slammed home directly from the app (middle-ware). I write relatively large blocks (millions of records) to naked temporary tables and then let straight sql read from there and insert into final tables in chunks.P {margin-top:0;margin-bottom:0;} Nota Bene:
Almost all official interfaces to/from Oracle are coded in Java
FWIK google's implementations are 95% python
(although you would need to understand JSON formatting for import/export requirements)
for those reasons i tread lightly before disparaging either language
Going Forward:
try to implement PL/SQL that rob/joshua mentioned
if you're calling no-joy after implementing PL/SQL
then we can take a look at interfacing to Postgres ETL binaries with a JNI interface
provided the JNI is spot on with signatures for each referenced function
Un Saludo
mFrom: Rob Sargent <robjsargent@gmail.com>
Sent: Monday, December 7, 2020 11:16 AM
To: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Subject: Re: PL/java
On 12/7/20 8:25 AM, Adrian Klaver wrote:
> On 12/7/20 7:18 AM, Hemil Ruparel wrote:
>> I want to say this. I never liked any extension language. It's like
>> Java is not meant to interact with databases.
>
> The JDBC folks might disagree.
>
That interaction is strictly sql to db, data to app. As it should be.
As of Java-16 there is a replacement for JNI which allows direct calling of native interfaces without the need for hand coded stub code.
On Monday, 7 December 2020 22:10:01 GMT Martin Gainty wrote:
> Nota Bene:
> Almost all official interfaces to/from Oracle are coded in Java
> FWIK google's implementations are 95% python
> (although you would need to understand JSON formatting for import/export
> requirements) for those reasons i tread lightly before disparaging either
> language
>
> Going Forward:
> try to implement PL/SQL that rob/joshua mentioned
> if you're calling no-joy after implementing PL/SQL
> then we can take a look at interfacing to Postgres ETL binaries with a JNI
> interface provided the JNI is spot on with signatures for each referenced
> function
>
> Un Saludo
> m
>
> ________________________________
> From: Rob Sargent <robjsargent@gmail.com>
> Sent: Monday, December 7, 2020 11:16 AM
> To: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
> Subject: Re: PL/java
>
> On 12/7/20 8:25 AM, Adrian Klaver wrote:
> > On 12/7/20 7:18 AM, Hemil Ruparel wrote:
> >> I want to say this. I never liked any extension language. It's like
> >> Java is not meant to interact with databases.
> >
> > The JDBC folks might disagree.
>
> That interaction is strictly sql to db, data to app. As it should be.
Rob Sargent schrieb am 07.12.2020 um 23:22: > If I'm tracking correctly I can say the java implementation of > CopyManager is, to me, blindingly fast. So if the E and the T are in > java then certainly the L can be also. I can confirm that using CopyManager in JDBC has pretty much the same performance as using COPY ... FROM STDIN in e.g. psql Thomas
Hi,
My concern is a purely commercial, in this case.
We work only for “large” companies. Only telecommunications operators (more than 5 million subscribers)
In this environment the “IBM / SAP / Accenture” effect is very strong - “I chose the leader, it is not my fault that it failed”
So, having something like PL/java when it is not “supported” by anyone with a markeatable name is always a barrier.
Furthermore, if it is not in the Postgres.org supported things, it will not be available in AWS RDS service, AWS Aurora, Azure xyz, Citus…, which limits our deployment options.
Thanks,
On 07-12-2020, at 14:45, Adrian Klaver <adrian.klaver@aklaver.com> wrote:On 12/7/20 3:25 AM, Zé Rui Marques wrote:Hi,
I am the lead architect in a small firm that develops a very specialised ETL platform.
Traditionally, we have used Oracle and PL-SQL, and we are now porting everything to Postgres.
All of our code outside of the database is java and I wiash that all of our code within the database to be also in java.
The PL/java “add-on” is not supported directly by Postgres.
I would like to ask if there is a plan to include it as an official procedural language. If so, when?
None that I have heard of. Even if the decision where to made today it would likely a couple of years before it would be included, so that is not going to help you. What is your concern?Thanks,
*—*
*Zé Rui Marques*
--
Adrian Klaver
adrian.klaver@aklaver.com