Am Samstag, 25. März 2006 17:27 schrieb Stephen Frost:
> I think what Peter would want is for us to track CURRENT_USER (the role
> who logged in) and to always add the CURRENT_USER to the list of roles
> available after a 'SET ROLE'. That would at least get us a little
> closer to the spec though I'm not sure if it matches what other DBs do.
This is sort of but not really what I meant. What I think would work rather
elegantly is having both a current_user and a current_role and having the
current_role set to current_user on login. (The SQL standard would require
the current role to be empty at login.) Then you get exactly the traditional
group behavior. You can also use SET ROLE to set the current role (but not
the current user) to some other permissible role. This will give you the
applicable privileges of your current user and that new role. The nice thing
about this is that this gives you both traditional PostgreSQL behavior by
default and completely SQL conforming behavior if you ask for it. (If we are
really ambitious, we can let people put their preferred current_role into
their session startup settings to give them exact SQL standard behavior by
default without requiring SET ROLE NONE first.) Note that we don't need any
inherit feature at all for any of that, nor does this require separate user
and role entities.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/