On Fri, Sep 5, 2008 at 7:37 PM, Heikki Linnakangas < [EMAIL PROTECTED]> wrote:
> So, you'll implement the part of SQL-MED that deals with specifying remote > connections, e.g something like "CREATE CONNECTION" (no, I haven't looked at > what the syntax actually is)? > > Yeah, that sounds like a good idea. We should get that into core, and > modify contrib/dblink to use it as well. It's just a small part of SQL-MED, > but it's a start, and it's useful for these other projects. > Yes that's the plan. > > > Marko Kreen wrote: > >> In the previous discussion there was mentioned that Postgres should >> move to the SQL-MED direction in remote connection handling. >> >> SQL-MED specifies that connections should have names and referenced >> everywhere using names. PL/Proxy currently does not conform to that >> standard - it uses connection strings directly. Although it could >> made work with SQL-MED backend, it would look ugly. >> >> So I'd like to withdraw PL/Proxy from commitfest and rework it's >> connection handling scheme to be also name->connstr based. Idea will >> be that it will have user-definable connection handling backend, >> which operates on named connections. And in the future we can >> plug in a backend that reuses connection info from builtin SQL-MED store. >> >> Although the current connection handling works and is secure it has >> a deficiency that it's bit hard to hide the password that is used >> for connecting. User can either play with table/function permissions >> and SECURITY DEFINER functions but that's complex. Or he can put >> passwords into .pgpass - this is easy and secure but has the problem >> that the file is not manageable from inside database. >> >> So PL/Proxy needs new SQL-MED based scheme that fixes it. When this >> is ready we can re-discuss the builtin vs. PL-based remote functions. >> As I don't plan to work on it near-term there is no point polluting >> the commitfest page with it. >> >> [ There was a attempt to paint the .pgpass based password handling >> insecure because dblink makes the file world-readable. I still >> fail to see how this any way points to flaws of the scheme... ] >> >> > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
