Joe Conway wrote:
I'm mainly concerned about re-opening security holes that we spent a lot of time debating and subsequently closing. I suspect if we assume that any FDW-derived connect string can bypass the checks we put in place, we will regret it later. But I'm open to arguments on both sides...
Can you elaborate what security issues you are concerned about?
It seems to me that get_connect_string() (or whatever we decide to call it), is very libpq specific, and therefore belongs with postgresql_fdw.c rather than foreign.c. But if we can't reach a consensus there is no harm in leaving it as a dblink.c specific static function either.
postgresql_fdw.c is a module with a defined API. I don't see what you would achieve by putting an ad hoc function in there.
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
