Re: [HACKERS] Re: PostgreSQL reference manual (groups)
David Gould wrote:
Bruce Momjian writes:
Stephane Lajeunesse writes:
A create group <groupname> is still missing in the grammar,
I'm working on this.. Should have something working around the end of
this week (for ALTER USER and CREATE USER).Please let me use this to tell you all that I would like to get notice of
each change to gram.y. I am currently modelling ecpg's parser after gram.y
to get good syntax checking. So I have to make these changes, too.Good idea on telling you of each change, but I also recommend that every
time you update the ecpg grammer, you save a copy the gram.y that you
used to do it, so later when you need to get it back in sync, you can do
a diff on the old and new one to see each change so you don't miss any.Consider also not updateing the grammar. The strength of PostgreSQL is that
functions can be added to work inside the server. These functions can often
do whatever is being proposed as new syntax.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');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.And, in keeping with the recent anti-bloat thread, these can be loadable
extensions, not part of the core. So if you don't use groups, you don't pay
for them.
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
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
Andreas is right.
Hooray for "roles" -- this is indeed the only way to preserve
the DBA's sanity across personnel turnover in key entry and
front desk, etc. definitely a core item.
A place where Sybase falls on its heinie (yes, I can admit
that their engine is less than perfect :-)) is that users
can only belong to *one* "group". This is frustrating,
and I'd love to see the ability to associate users with
multiple roles, rather than creating an elaborate system
of hierarchical role defs.
Gee, this PG discussion just gets more and more exciting as
it goes on.
de
.............................................................................
:De Clarke, Software Engineer UCO/Lick Observatory, UCSC:
:Mail: de@ucolick.org | "There is no problem in computer science that cannot:
:Web: www.ucolick.org | be solved by another level of indirection" --J.O. :