pgcentralfoundation
[Question] Foreign Data Wrapper
Is there any plan to create a safe abstraction for creating a foreign data wrapper?
I know that there are crate wrappers, but why not move this framework to the pgrx repository?
That repo hosts several readymade FDWs and we would be pretty uninterested in maintaining various wrappers between various different DBs.
granted, if @burmecia wants to upstream some code, pretty sure we'll take some of it, but I don't see us adopting it wholesale.
I'm more interested in the safe abstraction of FDW because FDW FFI looks verbose.
that'd be great if we can upstream the wrappers framework. Although there are some code for specific use, it should be possible to port the generic interface to upstream. Do you have ideas what kind of safe abstraction do you want to see in pgrx?
For my purposes, the current design of the ForeignDataWrapper trait and the wrappers_fdw macro is sufficient.
I'm not too picky here I think about overall design, but I might need to better understand the lifetimes involved in FDWs and to what extent what things are modeled.
@burmecia For example, one of the things I'm curious about is supabase_wrappers::interface::Cell. It seems like a type that is fully "lifted" from... Postgres(?) into Rust. I'm not sure why this highly abstracted type that allows essentially anything to be dynamically present is used instead of something static. External databases do allow highly dynamic typing, but Postgres is a bit more strict on these sorts of things, which helps pgrx greatly.
There is probably a good reason, but the repo lacks a description of these sorts of "high-level" decisions. I can't find it either in something like an ARCHITECTURE.md or type-level documentation. There is some documentation hosted on https://fdw.dev but it only goes into "what is a foreign data wrapper", not so much the specifics.
Those types in supabase_wrappers::interface::Cell are mainly to provide a simplified type abstraction for developers, so they don't need to directly talk with pgrx types. It originally only covered a small subset of pgrx types, but gradually expanded later on. If they are moved to pgrx, I don't think that abstraction is needed and can be built on pgrx types directly.