On 11/21/2016 03:59 PM, Corey Huinker wrote: > On 11/21/2016 02:16 PM, Tom Lane wrote: >> The dblink docs recommend using dblink_fdw as the FDW for this purpose, >> which would only accept legal connstr options. However, I can see the >> point of using a postgres_fdw server instead, and considering that >> dblink isn't actually enforcing use of any particular FDW type, it seems >> like the onus should be on it to be more wary of what the options are.
> I have to admit, this was the first I'd heard of dblink_fdw. I'm glad it > exists, though. And yes, I'd like to be able to use postgres_fdw entries > because there's value in knowing that the connection for your ad-hoc SQL > exactly matches the connection used for other FDW tables. > I'm happy to write the patch, for both v10 and any back-patches we feel > are necessary. I looked at Corey's patch, which is straightforward enough, but I was left wondering if dblink should be allowing any FDW at all (as it does currently), or should it be limited to dblink_fdw and postgres_fdw? It doesn't make sense to even try if the FDW does not connect via libpq. Maybe if "CREATE FOREIGN DATA WRAPPER" had a way to specify that the FDW supports a libpq connection it would make sense to allows other FDWs with this attribute, but since there is none the current state strikes me as a bad idea. Thoughts? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
signature.asc
Description: OpenPGP digital signature