Re: Role incompatibilities - Mailing list pgsql-hackers

Sorry to ressurect this thread.  However, I've been playing with the new
role system and I'd prefer to keep CURRENT_USER as the login user, and
not making it a synonymn for CURRENT_ROLE.  In my application, I love the
ability to "shed" privleges by "SET ROLE dataentry;".  However, I need
CURRENT_USER to remain as 'clark' for audit trail triggers (recording
that 'dataentry' changed a particular order is kinda useless).

I have a related information_schema question.  Tom said that I could
probably use "login" or "inherit" to determine which 'roles' are users,
and which are really roles.  Is this still the advice?  That said,
shouldn't PostgreSQL just call this mixed-thingy an 'authority' to
reduce confusion.  Then role-is-authority and user-is-authority.
Probably too late, but, just in case it is still changable...

My deeper question is... from the information_schema, is it possible
(both in theory via definition, and in pratice via implementation) to
obtain two things:
 (a) the roles to which I can do "SET ROLE" with, I guess this is     my granted roles?
 (b) the roles to which I currently am using for my permission(s),     or simply, the role inherit graph and my current
role

Thanks for your time,

Clark

P.S.  There isn't a way to list "all roles" from the information_schema,     except via DISTINCT on a table that refers
tothem?
 

On Mon, Apr 10, 2006 at 03:41:59PM -0400, Bruce Momjian wrote:
| 
| Is there a TODO here?
| 
| ---------------------------------------------------------------------------
| 
| Peter Eisentraut wrote:
| > Am Samstag, 25. M?rz 2006 16:10 schrieb Tom Lane:
| > > No, the current implementation is a compromise between exact standards
| > > compatibility and backwards compatibility with our historical "groups"
| > > behavior.  I'm not really prepared to toss the latter overboard.
| > 
| > My two major sticking points here are the SET ROLE command and the noinherit 
| > feature.  The SET ROLE command is not required by our historical group 
| > behavior (because we didn't have it before) and does not do what the SQL 
| > standard says it should do.  The noinherit feature is not required by the 
| > historical group behavior (because groups are yes-inherit) and is not in the 
| > SQL standard either.  So these two features were just mistakes as far as I 
| > can tell.
| > 
| > I'm not passing judgement on whether a command like the currently implemented 
| > SET ROLE command or a feature like the currently implemented noinherit 
| > feature is useful.  They are just not in line with either the historical 
| > group behavior or the SQL standard.
| > 
| > -- 
| > Peter Eisentraut
| > http://developer.postgresql.org/~petere/
| > 
| > ---------------------------(end of broadcast)---------------------------
| > TIP 1: if posting/reading through Usenet, please send an appropriate
| >        subscribe-nomail command to majordomo@postgresql.org so that your
| >        message can get through to the mailing list cleanly
| > 
| 
| -- 
|   Bruce Momjian   http://candle.pha.pa.us
|   EnterpriseDB    http://www.enterprisedb.com
| 
|   + If your life is a hard drive, Christ can be your backup. +
| 
| ---------------------------(end of broadcast)---------------------------
| TIP 3: Have you checked our extensive FAQ?
| 
|                http://www.postgresql.org/docs/faq
|