On Mon, Dec 19, 2016 at 6:48 AM, Joe Conway <mail@joeconway.com> wrote: > 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?
libpq is proper to the implementation of the FDW, not the wrapper on top of it, so using in the CREATE FDW command a way to do the decision-making that does not look right to me. Filtering things at connection attempt is a better solution. -- Michael
The only benefit I see would be giving the user a slightly more clear error message like ('dblink doesn't work with %', 'mysql') instead of the error about the failure of the connect string generated by the options that did overlap.
Gaming out the options of a Wrapper X pointing to server Y:
1. Wrapper X does not have enough overlap in options to accidentally create a legit connect string: Connection fails, user gets a message about the incompleteness of the connection.
2. Wrapper X has enough options (i.e. user+host+dbname,etc) to generate a legit connect string (with matching port), but server+port pointed to by X isn't listening or doesn't speak libpq:
Connection fails, user gets an error message.
3. Wrapper X has enough options (i.e. user+host+dbname,etc) to generate a legit connect string (without matching port), but server+5432 pointed to by X doesn't speak libpq:
Whatever *is* listening on 5432 has a chance to try to handshake libpq-style, and I guess there's a chance a hostile service listening on that port might know enough libpq to siphon off the credentials, but the creds it would get would be to a pgsql service on Y and Y is already compromised. Also, that vulnerability would exist for FDWs that do speak libpq as well.
4. Wrapper X has enough overlap in options to create a legit connect string which happens to speak libpq:
Connection succeeds, and it's a feature not a bug.
