From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Chris Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL/MED compatible connection manager |
Date: | 2008-10-28 23:58:27 |
Message-ID: | 1225238307.13402.46.camel@huvostro |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2008-10-27 at 16:50 -0400, Chris Browne wrote:
> martin(dot)pihlak(at)gmail(dot)com (Martin Pihlak) writes:
> > Tons of details have been omitted, but should be enough to start discussion.
> > What do you think, does this sound usable? Suggestions, objections?
>
> Slony-I does some vaguely similar stuff in its handling of "connection paths"; here's the schema:
I think the whole issue was initially raised by "insecurity", as dblink
conrib module exposed connection strings to all users, and SQL/MED was
seen as a "standard" way to hide it.
The simple credentials hiding could of course be achieved by having
something similar to pg_user/pg_shadow and some SECURITY DEFINER
functions for actually opening the connections, but probably it seemed
easier to at least base it on standards, so we can actually start with
pg_remote_server table public
pg_user_mapping_shadow table (restricted)/ pg_user_mapping view(public)
and some functions with proper grants to match the subset that Martin
outlined in http://wiki.postgresql.org/wiki/SqlMedConnectionManager
if we've got that working, then we could move to massaging it into the
parser to provide standard SQL/MED syntax.
so I think that first we should agree on functionality and get the few
system (?) tables and functions done, and worry about parser changes
once the actual functionality is field tested.
------------------------------------------
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-10-29 00:12:29 | Re: UUID-OSSP Contrib Module Compilation Issue |
Previous Message | Gregory Stark | 2008-10-28 23:54:21 | Re: Proposal of PITR performance improvement for 8.4. |