Stephen Frost <[EMAIL PROTECTED]> writes:
> It sounds like this is essentially if 'SET ROLE all;' is allowed or not.
> If you disallow 'SET ROLE all;' (and therefore not do it on session
> start) then you would get this behaviour. I certainly see that as a
> reasonable option though I think we'd want to allow 'SET ROLE all;' for
> backwards compatibility to group-based systems.
'SET ROLE all' is nonstandard; it will complicate the implementation a
great deal; and it creates a problem with the permissions environment of
a SECURITY DEFINER function being different from that seen at the outer
level by the same user.
I think a better answer is to have a "rolinherit" flag in pg_authid,
which people can set "off" for spec compatibility or "on" for backwards
compatibility to the GROUP feature. In either setting, the permissions
given to a particular authid are clear from pg_authid and don't vary
depending on magic SET variables.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
