Re: Role incompatibilities

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 to them?

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(at)postgresql(dot)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
|