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... ]
