On Tue, Apr 10, 2012 at 9:47 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> I don't understand what the heck you're talking about, TBH. From a user
> perspective there is nothing to work out. It will look like any other FDW.
yes, that is correct.
> The implementor of the FDW handler will have to work out the glue between
> postgres and the JVM, but that's not going to be you, right?
Correct. I think I understand what you're driving at. Basically,
pl/java is the glue. my thinking was inside the FDW callbacks to to do
SPI calls to invoke the pl/java routines. Unlike other fdw
implementations which mostly wrap C libraries -- which makes things
very easy since you can directly jump into the routine for foreign
execution -- a luxury we don't have. We have to invoke java and there
are two basic ways to tie into the java runtime: one is to jump
through SPI via the SQL executor. The other is JNI into the pl/java
jvm which I think you were hinting was the better approach.
Doing an SPI call from a FDW callback is inefficient -- that's an
extra call into the executor (although you can prepare it) and you
have to walk the SPI result just to build it up again in the FDW
iterator. A JNI solution instead would jump into the jvm and do java
invocation and I believe would drive the difficulty of this project up
a couple of notches whereas a SPI approach utilizes a well documented
interface. We're not stuck on the approach though -- I'm pushing Atri
to get the environment set up so we can explore alternative solutions.
In other words, our proposal is basically pretty similar to what you'd
end up with if you wrapped dblink into a fdw making dblink calls
inside the fdw over spi.
merlin
