Обсуждение: User mapping
Hi,
I'm looking at adding user mapping support. My first idea was to add
them as children of foreign servers, but it doesn't seem this was a
really good idea. They have no OIDs, no owners, no comments... geez, no
nothing actually. They don't seem like objects, meaning they can't be in
their own node (with no OID, refresh wouldn't work for example).
My second idea was to add a "User mapping" tab on the foreign server
dialog, so that we could directly add user mapping to servers. It still
seems a good idea to me.
SQL commands are quite simple:
CREATE USER MAPPING FOR { user_name | USER | CURRENT_USER | PUBLIC }
SERVER server_name
[ OPTIONS ( option 'value' [ , ... ] ) ]
ALTER USER MAPPING FOR { user_name | USER | CURRENT_USER | PUBLIC }
SERVER server_name
OPTIONS ( [ ADD | SET | DROP ] option ['value'] [, ... ] )
DROP USER MAPPING [ IF EXISTS ] FOR { user_name | USER | CURRENT_USER |
PUBLIC } SERVER server_name
There's something that bugs me right now: the OPTIONS clause. Can't
think of a good UI for it.
Do you think user mapping should have its own node? or that we could
handle them in a tab of the foreign server dialog?
I'll be glad to hear about any ideas you could have on this subject :)
Thanks.
--
Guillaume
http://www.postgresql.fr
http://dalibo.com
On 23 March 2011 22:10, Guillaume Lelarge <guillaume@lelarge.info> wrote:
> Hi,
>
> I'm looking at adding user mapping support. My first idea was to add
> them as children of foreign servers, but it doesn't seem this was a
> really good idea. They have no OIDs, no owners, no comments... geez, no
> nothing actually. They don't seem like objects, meaning they can't be in
> their own node (with no OID, refresh wouldn't work for example).
>
> My second idea was to add a "User mapping" tab on the foreign server
> dialog, so that we could directly add user mapping to servers. It still
> seems a good idea to me.
>
> SQL commands are quite simple:
>
> CREATE USER MAPPING FOR { user_name | USER | CURRENT_USER | PUBLIC }
> SERVER server_name
> [ OPTIONS ( option 'value' [ , ... ] ) ]
>
> ALTER USER MAPPING FOR { user_name | USER | CURRENT_USER | PUBLIC }
> SERVER server_name
> OPTIONS ( [ ADD | SET | DROP ] option ['value'] [, ... ] )
>
> DROP USER MAPPING [ IF EXISTS ] FOR { user_name | USER | CURRENT_USER |
> PUBLIC } SERVER server_name
>
> There's something that bugs me right now: the OPTIONS clause. Can't
> think of a good UI for it.
Why not something similar what exists for database variables? i.e.
option=>value.
As for having them as child nodes of a foreign server, I think that
would work well. Each node member would be a user, and wouldn't the
oid from pg_user_mapping be available to display in the properties.
You'd then have oid and options. Granted it looks very minimalistic,
but then I think it's more intuitive.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Le 23/03/2011 23:39, Thom Brown a écrit :
> On 23 March 2011 22:10, Guillaume Lelarge <guillaume@lelarge.info> wrote:
>> Hi,
>>
>> I'm looking at adding user mapping support. My first idea was to add
>> them as children of foreign servers, but it doesn't seem this was a
>> really good idea. They have no OIDs, no owners, no comments... geez, no
>> nothing actually. They don't seem like objects, meaning they can't be in
>> their own node (with no OID, refresh wouldn't work for example).
>>
>> My second idea was to add a "User mapping" tab on the foreign server
>> dialog, so that we could directly add user mapping to servers. It still
>> seems a good idea to me.
>>
>> SQL commands are quite simple:
>>
>> CREATE USER MAPPING FOR { user_name | USER | CURRENT_USER | PUBLIC }
>> SERVER server_name
>> [ OPTIONS ( option 'value' [ , ... ] ) ]
>>
>> ALTER USER MAPPING FOR { user_name | USER | CURRENT_USER | PUBLIC }
>> SERVER server_name
>> OPTIONS ( [ ADD | SET | DROP ] option ['value'] [, ... ] )
>>
>> DROP USER MAPPING [ IF EXISTS ] FOR { user_name | USER | CURRENT_USER |
>> PUBLIC } SERVER server_name
>>
>> There's something that bugs me right now: the OPTIONS clause. Can't
>> think of a good UI for it.
>
> Why not something similar what exists for database variables? i.e.
> option=>value.
>
Yeah, good idea. I like it. But I'm not sure it would work well.
> As for having them as child nodes of a foreign server, I think that
> would work well. Each node member would be a user, and wouldn't the
> oid from pg_user_mapping be available to display in the properties.
> You'd then have oid and options. Granted it looks very minimalistic,
> but then I think it's more intuitive.
>
You probably don't need the OID to display the properties dialog. But
you need a unique way to identify a user. The pair username/foreign
server could be it.
I agree that nodes would be more intuitive. But I'm not sure it really
makes sense (or is consistent with the rest of the UI).
--
Guillaume
http://www.postgresql.fr
http://dalibo.com
On Wed, Mar 23, 2011 at 10:10 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Hi, > > I'm looking at adding user mapping support. My first idea was to add > them as children of foreign servers, but it doesn't seem this was a > really good idea. They have no OIDs, no owners, no comments... geez, no > nothing actually. They don't seem like objects, meaning they can't be in > their own node (with no OID, refresh wouldn't work for example). They do have OIDs - and even without, refresh can be made to work easily. We'd just need to refresh based on the unique key (umuser + umserver). > My second idea was to add a "User mapping" tab on the foreign server > dialog, so that we could directly add user mapping to servers. It still > seems a good idea to me. After thinking about it last night, I think the treeview is the correct method. Add a user mappings node under the server. You're correct in that is would be pretty simple, but that doesn't matter. I would expect to see two tabs on the properties dialogue, one with OID and username (and comment, if that is added in PG), and one with a listview of key/value pairs for the options, in a similar layout to the role/database variables tab. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Le 24/03/2011 11:21, Dave Page a écrit : > On Wed, Mar 23, 2011 at 10:10 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Hi, >> >> I'm looking at adding user mapping support. My first idea was to add >> them as children of foreign servers, but it doesn't seem this was a >> really good idea. They have no OIDs, no owners, no comments... geez, no >> nothing actually. They don't seem like objects, meaning they can't be in >> their own node (with no OID, refresh wouldn't work for example). > > They do have OIDs - and even without, refresh can be made to work > easily. We'd just need to refresh based on the unique key (umuser + > umserver). > Don't remember what I did yesterday, but you're right. They have OIDs. That's good news. >> My second idea was to add a "User mapping" tab on the foreign server >> dialog, so that we could directly add user mapping to servers. It still >> seems a good idea to me. > > After thinking about it last night, I think the treeview is the > correct method. Add a user mappings node under the server. You're > correct in that is would be pretty simple, but that doesn't matter. I > would expect to see two tabs on the properties dialogue, one with OID > and username (and comment, if that is added in PG), and one with a > listview of key/value pairs for the options, in a similar layout to > the role/database variables tab. > Yeah, will do. -- Guillaume http://www.postgresql.fr http://dalibo.com