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