Subject | Re: [Firebird-Architect] User name SYSDBA |
---|---|
Author | Jim Starkey |
Post date | 2005-08-04T15:41:08Z |
Martijn Tonies wrote:
user to have more than one role per session is non-standard, you want to
invent a whole new non-standard SQL object of group that is otherwise
identical to role except that a) groups aren't specified at login, and
b) users can be members of serveral groups.
Both are non-standard, but changing the rules on roles is less so, less
work to implement, less work to document, and less confusing to the poor
DBA who would need to figure out when to use a role, when to use a
group, and how to figure it when he guessed wrong.
Extending the standard to allow a user to have latent roles that can be
activated or deactived at runtime is a pure extension -- if you don't
explicitly activate or deactivate roles at runtime, it preserves SQL
semantics.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>Tell me if this is a fair summary of your position. Because allowing a
>
>Exactly. Given that "role" is implemented according to the standard,
>leave it be. A user could always be part of a "group" and inherited all
>privileges for that "group". It could be assigned to multiple groups and
>get all privileges after login, without the need to specify the groupname
>on login or switch groups.
>
>
>
user to have more than one role per session is non-standard, you want to
invent a whole new non-standard SQL object of group that is otherwise
identical to role except that a) groups aren't specified at login, and
b) users can be members of serveral groups.
Both are non-standard, but changing the rules on roles is less so, less
work to implement, less work to document, and less confusing to the poor
DBA who would need to figure out when to use a role, when to use a
group, and how to figure it when he guessed wrong.
Extending the standard to allow a user to have latent roles that can be
activated or deactived at runtime is a pure extension -- if you don't
explicitly activate or deactivate roles at runtime, it preserves SQL
semantics.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376