Re: dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

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