Uh oh!
There was an error while loading. Please reload this page.
Skeleton of bottom-up FDW - #530
Conversation
Added quick sketch of bottom-up FDW java and C. It's not remotely functional - but provides a quick look at what a bottom-up approach may require on the pl/java side. I assume the C backend will use the 'simple_fdw' I'm developing elsewhere so the main thing we need on the backend is a way to actually provide a few functions to the backend and then have the backend make the necessary JNI calls. One complication is that a wrapper may have multiple servers, each server can have multiple tables, and each table can have multiple (possibly concurrent) queries. It would be nice if we could reuse any common wrappers and servers... but for the first efforts it's probably fine to treat it as one-to-one-to-one as long as we don't close any doors.
Updated FDW - I had started but got distracted. This is definitely hand-wavy but it should be good enough to get a good feel on whether this is a viable approach. The initial java implementation should be something simple, e.g, a class with a static List with a few values like (1, 'red'), (2, 'greem'), etc. That means the only think we need to track is the current position within the array and to provide the current row in an acceptable format.
beargiles
commented
May 27, 2025
I noted elsewhere that I borrowed heavily from the existing UDT but there's a huge difference since a UDT must expose its methods while a FDW should hide them. (It will still need to expose two - but they're only called when the FOREIGN TABLE is created.) That means that all of the That said... DURING DEVELOPMENT it might be useful to expose these methods (plus state) in order to test the implementation outside of the FDW framework. However this would be a stopgap measure and only used until there's no doubt that the 'glue' is working as expected. |
Skeleton of bottom-up FDW design.
The idea is to fully implement the FDW in the C backend but provide an SPI that can be implemented in java and called via JNI. The java should be completely ignorant of the fact that it's called by a PostgreSQL FDW.
This is the opposite of a top-down design where you try to implement everything in java until you have no choice but to call the backend. This approach has some benefits - but comes at the very high expense of requiring the java code to duplicate a ton of functionality that's already implemented by the back end. That's a lot of extra effort and begging for inconsistent behavior.
The final solution may be somewhere in the middle but if so I hope we can use annotations and automated code generation instead of requiring individual FDW developers to learn backend details.