> > > 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





Mon, 23 Mar 1998 18:10:12 +-100
Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
AW: [HACKERS] Re: PostgreSQL reference manual
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

Mon, 23 Mar 1998 19:23:44 -0500
Stephane Lajeunesse <slajeunesse@sympatico.ca>
Re: AW: [HACKERS] Re: PostgreSQL reference manual
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

Tue, 24 Mar 1998 09:44:36 +0100 (CET)
Michael Meskes <meskes@topsystem.de>
Re: AW: [HACKERS] Re: PostgreSQL reference manual
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'


Tue, 24 Mar 1998 11:11:48 +0000 (UTC)
"Jose' Soares Da Silva" <sferac@proxy.bazzanese.com>
Re: AW: [HACKERS] Re: PostgreSQL reference manual
> 
> 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)

Tue, 24 Mar 1998 20:47:01 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: AW: [HACKERS] Re: PostgreSQL reference manual
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.


Tue, 24 Mar 1998 18:34:09 -0800 (PST)
dg@illustra.com (David Gould)
Re: AW: [HACKERS] Re: PostgreSQL reference manual
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

Wed, 25 Mar 1998 15:43:06 +0100 (CET)
Michael Meskes <meskes@topsystem.de>
Re: AW: [HACKERS] Re: PostgreSQL reference manual
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

Wed, 25 Mar 1998 15:45:09 +0100 (CET)
Michael Meskes <meskes@topsystem.de>
Re: AW: [HACKERS] Re: PostgreSQL reference manual
> 
> 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)

Wed, 25 Mar 1998 09:52:19 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: AW: [HACKERS] Re: PostgreSQL reference manual
 > 
> 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)

Wed, 25 Mar 1998 09:54:54 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: AW: [HACKERS] Re: PostgreSQL reference manual