On 9/12/08, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Marko Kreen escribió: > > > Currently dblink allows regular users to initiate libpq connection > > to user-provided connection string. This breaks the default > > policy that normal users should not be allowed to freely interact > > with outside environment. > > Since people is now working on implementing the SQL/MED stuff to manage > connections, should we bounce this patch? With luck, the CREATE > CONNECTION (?) stuff will be done for the next commitfest and we can > just switch dblink to use that instead. > > http://archives.postgresql.org/message-id/[EMAIL PROTECTED] > > Thoughts? Can we really expect SQL/MED connection mgmt to be done for > the next fest?
I will not have time for it. If you want to have it in 8.4, somebody else needs to step forward. It should not be that hard actually, for dblink and plproxy only following is needed (for exact syntax look at sql standard): - CREATE/ALTER/DROP CONNECTION <name> <details> - CREATE/DROP USER MAPPING FOR <conn> <user> ... <password> - system table for connection details - system table for user mapping - basically access control and passwords - C API for connection parameter fetching with access control. It should not try to handle actual connections as it's users may have different requirements (eg plproxy wants to use async API for connecting), and anyway it should handle non-Postgres connection too in the future. - invalidation mechanism if info in system tables change The syntax better be SQL-MED compliant (as far as we want to be). The SQL-MED seems to define further API for both C and SQL, but there is no need to try to implement those. As there is simply no need for it. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
