Zeugswetter Andreas wrote:
>
> >So, instead of cluttering up the grammar with non-standard SQLish stuff
> >to handle things like groups, just create an administrative function to
> >do this job.
> >
> >* return create_group('groupname');
> >* return add_user_to_group('groupname', 'username');
> >* return drop_group('groupname');
I actually tought about this but would have considered this a 'patch'
until native support.
> >
> >These can be written in C, in SQL, or what ever far more quickly and with
> >much less risk of destabilizing the system than the parser can be modified.
> >It also avoids making incompatibility with ecpg.
The syntax for ALTER USER .. IN GROUP and CREATE USER IN GROUP is
already in gram.y. The arguments are also passed to user.c. The only
thing needed was implementation. The only thing not in gram.y is CREATE
GROUP. BTW, I have a working version of alter user and create user.
Also started working on delete user (removall from all groups). Hope to
clean up the code and release it soon.
> I am sorry, but I have to disagree here. The group functionality is part of SQL92
> it is only called "role". In my opinion it is the only serious way to use the
> SQL permission stuff. I never grant rights directly to users, I always try to
> create task oriented roles, and then grant the users roles. Then if we get a new
> secretary I only have to grant secretary to the new user. Everything else would be a nightmare.
> There is only a misconcept in Informix, that makes roles rather useless,
> you have to say 'set role secretary;' in every session to actually get the rights, there is no
> default roles like in Oracle.
>
> Andreas
I totally support Andreas here. Roles or groups should be part of the
core RDBMS. I don't think telling users to load a module to have groups
or roles enabled would be appropriate when all other RDBMS support some
implementation of this off the shelf.
--
Stephane Lajeunesse.
Oracle and Sybase DBA
