From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: dblink vs SQL/MED - security and implementation details |
Date: | 2009-01-05 13:48:11 |
Message-ID: | 49620F9B.8050501@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-01-05 13:57:45 | Re: Many "loaded library" logs by preload libraries |
Previous Message | Tom Lane | 2009-01-05 13:46:52 | EmitWarningsOnPlaceholders is too quiet |