On Tue, Apr 10, 2012 at 9:47 AM, Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
