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