Re: dblink vs SQL/MED - security and implementation details
От | Peter Eisentraut |
---|---|
Тема | Re: dblink vs SQL/MED - security and implementation details |
Дата | |
Msg-id | 49620F9B.8050501@gmx.net обсуждение исходный текст |
Ответ на | dblink vs SQL/MED - security and implementation details (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: dblink vs SQL/MED - security and implementation details
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: