Re: Withdraw PL/Proxy from commitfest

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.

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