Re: GRANT role_name TO role_name ON database_name - Mailing list pgsql-hackers

From Clark C. Evans
Subject Re: GRANT role_name TO role_name ON database_name
Date
Msg-id 1369853241.27602.140661237262205.2DD9B948@webmail.messagingengine.com
Whole thread Raw
In response to Re: GRANT role_name TO role_name ON database_name  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Wed, May 29, 2013, at 09:45 AM, Stephen Frost wrote:
> * Albe Laurenz (laurenz.albe@wien.gv.at) wrote:
> > Maybe the db_user_namespace parameter can help:
> > http://www.postgresql.org/docs/9.2/static/runtime-config-connection.html#GUC-DB-USER-NAMESPACE
> 
> I doubt it and I wouldn't encourage anyone to use it even if it happened
> to help in this situation..

This feature won't help me, and I'd concur with Stephen that
I wouldn't encourage its use.    Auto-magical name-mangling 
sounds suspiciously like an application feature. 

The major problem isn't prefixing - you can do that in application 
logic easy enough.  The harder problem is that this convention 
would have to be respected by dump/restore and create database 
from template.   So, the application role auditor@sales would be
dumped in a serialization of the "sales" database; and, when 
restored into "sales-testing" would become "auditor@sales-testing".

Speaking of which, the choice of a @ delimiter is unfortunate, 
since email addresses (authenticated by Mozilla Persona) make 
lovely user names.   If a delimiter is used for name mangling, 
I'd lobby for a character that is an "unwise" RFC2396 character
and not a "reserved" RFC3986 character.   So, perhaps the
PIPE (|) or caret (^) would be good choices since those can 
be percent-encoded in valid emails, and don't have assigned
meanings as a standard URI. 

Best,

Clark



pgsql-hackers by date:

Previous
From: Abhishek Rai
Date:
Subject: Re: pg_stat_replication when standby is unreachable
Next
From: Daniel Farina
Date:
Subject: Re: Planning incompatibilities for Postgres 10.0