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 Tom Lane <tgl@sss.pgh.pa.us>
Re: dblink vs SQL/MED Peter Eisentraut <peter_e@gmx.net>
Re: dblink vs SQL/MED Joe Conway <mail@joeconway.com>
Re: dblink vs SQL/MED Joe Conway <mail@joeconway.com>
Re: dblink vs SQL/MED Martin Pihlak <martin.pihlak@gmail.com>
dblink vs SQL/MED - security and implementation details Joe Conway <mail@joeconway.com>
Re: dblink vs SQL/MED - security and implementation details Peter Eisentraut <peter_e@gmx.net>
Re: dblink vs SQL/MED - security and implementation details Joe Conway <mail@joeconway.com>
Re: dblink vs SQL/MED - security and implementation details Peter Eisentraut <peter_e@gmx.net>
Re: dblink vs SQL/MED - security and implementation details Martin Pihlak <martin.pihlak@gmail.com>
Re: dblink vs SQL/MED - security and implementation details Joe Conway <mail@joeconway.com>
Re: dblink vs SQL/MED - security and implementation details Peter Eisentraut <peter_e@gmx.net>
Re: dblink vs SQL/MED - security and implementation details Tom Lane <tgl@sss.pgh.pa.us>
Re: dblink vs SQL/MED - security and implementation details Peter Eisentraut <peter_e@gmx.net>
Re: dblink vs SQL/MED - security and implementation details Tom Lane <tgl@sss.pgh.pa.us>
Re: dblink vs SQL/MED - security and implementation details Martin Pihlak <martin.pihlak@gmail.com>
Re: dblink vs SQL/MED - security and implementation details Tom Lane <tgl@sss.pgh.pa.us>
Re: dblink vs SQL/MED - security and implementation details Peter Eisentraut <peter_e@gmx.net>
Re: dblink vs SQL/MED - security and implementation details Martin Pihlak <martin.pihlak@gmail.com>
Re: dblink vs SQL/MED Joe Conway <mail@joeconway.com>
Re: dblink vs SQL/MED Tom Lane <tgl@sss.pgh.pa.us>
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 по дате отправления
От: Fujii Masao
Дата:
Сообщение: log output of vxid
От: Martin Pihlak
Дата:
FAQ