Обсуждение: AW: [HACKERS] Re: PostgreSQL reference manual
> > > I have another question about GRANT/REVOKE: > > > > > > grant <privilege[,privilege,...]> > > > on <rel1>[,...<reln>] > > > to [public | GROUP <group> | <username>] > > > ^^^^^^^^^^^^^ > > > I don't know how to create a GROUP ? > > > > I believe that you use "CREATE USER groupname", and then can assign > > privileges to that pseudo-user/group, and then add users to that > > group. Have you tried that? > postgres=> create user grupo; > CREATE USER > postgres=> grant all on tmp to grupo; > CHANGE > create user joe in group grupo; > CREATE USER > postgres=> grant select on tmp to group grupo; > ERROR: non-existent group "grupo" Can someone tell us how "groups" work? I'm not finding enough clues just by looking in the parser, and haven't stumbled across it in the docs... Once a group is manually created with insert into pg_group values ... it can be used by the create user, alter user and grant to group syntax. A create group <groupname> is still missing in the grammar, it would simply need to do the insert. Groups are very helpful with many users that all need similar grants. You grant rights to the group and then grant groups to users. The ANSI92 naming is "role", if we enhance the group stuff maybe it would be good to convert to the "role" naming of group code, althougth I like "group" more. Andreas
Zeugswetter Andreas wrote: > > Once a group is manually created with insert into pg_group values ... > it can be used by the create user, alter user and grant to group syntax. > 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). > it would simply need to do the insert. Groups are very helpful with > many users that all need similar grants. You grant rights to the group > and then grant groups to users. The ANSI92 naming is "role", Oracle calls it "role" and Sybase calls it "group". -- Stephane Lajeunesse. Oracle and Sybase DBA
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. Michael -- Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH meskes@topsystem.de | Europark A2, Adenauerstr. 20 meskes@debian.org | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
On Mon, 23 Mar 1998, Zeugswetter Andreas wrote:
> > > > I have another question about GRANT/REVOKE:
> > > >
> > > > grant <privilege[,privilege,...]>
> > > > on <rel1>[,...<reln>]
> > > > to [public | GROUP <group> | <username>]
> > > > ^^^^^^^^^^^^^
> > > > I don't know how to create a GROUP ?
> > >
> > > I believe that you use "CREATE USER groupname", and then can assign
> > > privileges to that pseudo-user/group, and then add users to that
> > > group. Have you tried that?
> > postgres=> create user grupo;
> > CREATE USER
> > postgres=> grant all on tmp to grupo;
> > CHANGE
> > create user joe in group grupo;
> > CREATE USER
> > postgres=> grant select on tmp to group grupo;
> > ERROR: non-existent group "grupo"
>
> Can someone tell us how "groups" work? I'm not finding enough clues just
> by looking in the parser, and haven't stumbled across it in the docs...
>
> Once a group is manually created with insert into pg_group values ...
> it can be used by the create user, alter user and grant to group syntax.
> A create group <groupname> is still missing in the grammar,
> it would simply need to do the insert. Groups are very helpful with
> many users that all need similar grants. You grant rights to the group
> and then grant groups to users. The ANSI92 naming is "role",
> if we enhance the group stuff maybe it would be good to convert to the
> "role" naming of group code, althougth I like "group" more.
>
I created a group as Andreas said but now psql \z doesn't work anymore
It give me always a segmentation fault ... what's wrong...
postgres=> INSERT INTO pg_group VALUES ('tutti',200);
INSERT 318273 1
postgres=> CREATE USER jose IN GROUP tutti;
CREATE USER
SELECT * FROM pg_group;
groname|grosysid|grolist
-------+--------+-------
tutti | 200|
(1 row)
postgres=> GRANT ALL ON temp TO GROUP tutti;
CHANGE
postgres=> \z
$ Segmentation fault
jose'
> > 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. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
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.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- Linux. Not because it is free. Because it is better.
Bruce Momjian writes: > 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. Tom had the same idea. I wonder if you ever used that before. :-) Anyway, this is no doubt a very good idea. Thanks. Michael -- Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH meskes@topsystem.de | Europark A2, Adenauerstr. 20 meskes@debian.org | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
David Gould writes:
> 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 you want me to not check the syntax while parsing the embedded SQL code?
> 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');
But this is not embedded SQL.
> 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.
Okay, but I should at least check for ANSI SQL.
Michael
--
Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH
meskes@topsystem.de | Europark A2, Adenauerstr. 20
meskes@debian.org | 52146 Wuerselen
Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
> > Bruce Momjian writes: > > 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. > > Tom had the same idea. I wonder if you ever used that before. :-) > > Anyway, this is no doubt a very good idea. Thanks. > I believe I suggested it to the OpenLink people who mirror our libpq changes, and to the person who keeps the Japanese version of the FAQ. Really the only way to do it. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> > David Gould writes: > > 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 you want me to not check the syntax while parsing the embedded SQL code? What I think we was suggesting is that we add non-ANSI functionality as function calls rather than grammer changes with keywords. The only disadvantage is that it is a little more cumbersom, and less intuitive for users. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)