Re: [HACKERS] Regarding GSoc Application - Mailing list pgsql-jdbc

From Atri Sharma
Subject Re: [HACKERS] Regarding GSoc Application
Date
Msg-id 4f85975a.2a18440a.6a58.ffffa25e@mx.google.com
Whole thread Raw
In response to Re: [HACKERS] Regarding GSoc Application  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-jdbc
Hi all,

In continuation to the discussion regarding my JDBC wrapping FDW,I have been
talking to members of the community and I have two approaches on which I
would request your suggestions and opinions:



>I think we are back on the initial approach I proposed(hooking directly
into the JVM and executing Java code that calls JDBC).
>I think the best way to do this is create a JVM that executes the Java code
and give the control of the JVM to the native API.

>I agree,the only need of Pl/Java that is apparent here is the need of the
Java internals(JDK et al).If we set them up >independently,then,we can have
the FDW wrapping JDBC directly through JNI.JNI would call pure Java
functions to connect to the >JDBC.

In the above context,I think if we directly wrap JNI and call pure Java
routines(not using Pl/Java codes directly),we can build something on the
lines of Multicorn(a nice suggestion by Hitoshi) http://multicorn.org/

On the other hand,as suggested by John,we can use the Pl/Java routines that
already exist to build our FDW's API.This shall be the flow:


user application -> SQL -> PLjava FDW functions -> pljava code -> JDBC
-> foreign database

The user will have to pass security levels and permissions before being able
to get to the FDW.This would look to the user very much like dblink looks
now, and have similar security issues and mitigations.

Please let me know how to proceed further.

Atri



pgsql-jdbc by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: [HACKERS] Regarding GSoc Application
Next
From: "Atri Sharma"
Date:
Subject: Re: [HACKERS] Regarding GSoc Application