Indeed it is; TBH, having seen how easy this was to make, I wonder if there would be any merit to making a stripped-down postgres package which is just daemon + SQL parser + FDW interface (so no built-in storage engine) -- the FDW interface is amazing for building SQL interfaces for arbitrary data sets, but the whole postgres bundle seems a little heavy-weight and complex to install if that's the only thing you want it for...
Or I guess you could start from the other direction, and make a FDW/Multicorn-compatible API for SQLite? (Facebook's OSQuery is SQLite-based, but it looks like the virtual table interface over there is way more complex)
The interface is not quite as nice as Multicorn's but certainly nicer than the C/C++ SQLlite interface. But you could probably create a wrapper around apsw so it looked similar to Multicorn.
FYI, you can use ":memory:" as the sqlite data source, instead of having to conditionally drop the tables (unless you actually do want to store some persistent data on disk).
That would remove some of my hesitancy in letting this run as root for full process information. At least it limits what code could be exploited in the daemon process to some extent.
Or I guess you could start from the other direction, and make a FDW/Multicorn-compatible API for SQLite? (Facebook's OSQuery is SQLite-based, but it looks like the virtual table interface over there is way more complex)