Re: Withdraw PL/Proxy from commitfest

On Fri, Sep 5, 2008 at 7:37 PM, Heikki Linnakangas <
heikki(dot)linnakangas(at)enterprisedb(dot)com> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>