Re: [HACKERS] Regarding GSoc Application

Поиск
Список
Период
Сортировка
От Atri Sharma
Тема Re: [HACKERS] Regarding GSoc Application
Дата
Msg-id 4f85975a.2a18440a.6a58.ffffa25e@mx.google.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Regarding GSoc Application  (Merlin Moncure <mmoncure@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: [HACKERS] Regarding GSoc Application
Следующее
От: "Atri Sharma"
Дата:
Сообщение: Re: [HACKERS] Regarding GSoc Application