To: Joe Conway <mail@joeconway.com>
cc: "Hackers (PostgreSQL)" <pgsql-hackers@postgresql.org>,
	Peter Eisentraut <peter_e@gmx.net>
Subject: Re: dblink patches for comment 
In-reply-to: <4A232074.5020506@joeconway.com> 
References: <4A1C9C8C.6030405@joeconway.com> <20613.1243466644@sss.pgh.pa.us>
	<4A232074.5020506@joeconway.com>
Comments: In-reply-to Joe Conway <mail@joeconway.com>
	message dated "Sun, 31 May 2009 17:27:32 -0700"
Date: Mon, 01 Jun 2009 21:18:23 -0400
Message-ID: <193.1243905503@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Joe Conway <mail@joeconway.com> writes:
> Here's a much simpler SQL/MED support patch for dblink.

> This enforces security in the same manner for FOREIGN SERVER connections 
> as that worked out over time for other dblink connections. Essentially, 
> the FOREIGN SERVER and associated user MAPPING provides the needed info 
> for the libpq connection, but otherwise behavior is the same.

> I've also attached a doc patch.

The docs patch looks okay, except this comment is a bit hazy:

> +  -- Note: local connection must require authentication for this to work properly

I think what it means is

> +  -- Note: local connection must require password authentication for this to work properly

If not, please clarify some other way.  It might also be good to be a
bit more clear about what "fail to work properly" might entail.

As far as the code goes, hopefully Peter will take a look since he's
spent more time on the SQL/MED code than I have.  The only thing I can
see that looks bogus is that get_connect_string() is failing to handle
any quoting/escaping that might be needed for the values to be inserted
into the connection string.  I don't recall offhand what rules libpq
has for that, but I hope it at least implements doubled single quotes...

			regards, tom lane