Skip site navigation (1) Skip section navigation (2)

Re: Role syntax (or, SQL99 versus sanity)

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Role syntax (or, SQL99 versus sanity)
Date: 2005-06-28 18:38:14
Message-ID: 42C19916.5020700@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Tom Lane wrote:

>I'm looking at the problem Stephen Frost noted of not being able to
>duplicate the SQL99-specified syntax for GRANT/REVOKE with roles.
>
>The SQL99 spec has for GRANT (REVOKE has the identical issue):
>
>         <grant privilege statement> ::=
>              GRANT <privileges>
>                TO <grantee> [ { <comma> <grantee> }... ]
>                  [ WITH HIERARCHY OPTION ]
>                  [ WITH GRANT OPTION ]
>                  [ GRANTED BY <grantor> ]
>
>         <grant role statement> ::=
>              GRANT <role granted> [ { <comma> <role granted> }... ]
>                TO <grantee> [ { <comma> <grantee> }... ]
>                  [ WITH ADMIN OPTION ]
>                  [ GRANTED BY <grantor> ]
>
>Barring the appearance of one of the OPTION clauses, it is actually
>impossible to tell which kind of statement you are dealing with,
>other than by noticing whether the words appearing between GRANT and TO
>all look like known privilege keywords.  The bison conflicts Stephen
>was seeing come from the fact that we treat most of the privilege
>keywords as unreserved words, and so the ambiguity is fatal as far
>as bison is concerned.
>
>The only grammar-level solution I can see is to promote all of the
>following into some category of reserved word:
>	INSERT UPDATE USAGE DELETE RULE TRIGGER EXECUTE TEMPORARY TEMP
>which is pretty annoying, even though SQL99 gives us license to do so
>for most of them.  (But reserving RULE or TEMP would be contrary to
>spec.)
>
>Alternatively we might consider not distinguishing GRANT PRIVILEGE
>from GRANT ROLE at parse time, but sorting it out later.  The most
>extreme form of this would be to actually allow both things in the
>same GRANT:
>
>	GRANT INSERT, role1, UPDATE TO joe;
>
>treating WITH GRANT OPTION and WITH ADMIN OPTION as interchangeable
>spellings of the same thing (which they very nearly are anyway).
>
>One objection to this is that misspelling a privilege keyword would
>give you a complaint about "unknown role", which might be a bit
>confusing; but I suspect we cannot avoid that anyway --- there is
>absolutely no basis on which we can say that
>
>	GRANT INSIRT TO joe;
>
>isn't a GRANT ROLE operation, until we fail to find the role name.
>(Possibly we could alleviate this by adding a HINT.)
>
>These considerations also suggest that it'd be a good idea to disallow
>the privilege names (select insert etc) as role names.
>
>On the whole, the SQL99 committee should have followed Stephen's
>idea and made the syntax be "GRANT ROLE rolenames" ...
>
>Thoughts anyone?
>
>
>  
>

going backwards ...

. getting to SQL99 syntax might be a pain but we should do it, however 
unwise they were in choice of syntax.
. excluding named privileges from use as role names seems highly desireable
. thought on resolution
  - not sure if we can play games with %prec - I suspect we can't
  - could we get there if we declare the named privs as "reserved just 
for this purpose"? That would probably imply partitioning the unreserved 
keywords list.

cheers

andrew


In response to

pgsql-hackers by date

Next:From: Stephen FrostDate: 2005-06-28 18:45:06
Subject: Re: [PATCHES] Users/Groups -> Roles
Previous:From: Andrew DunstanDate: 2005-06-28 18:28:11
Subject: Re: Problem with dblink regression test

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group