Thread: Parser conflicts in extended GRANT statement

Entertaining parser conflicts again.  We would like to be able to parse:
   GRANT table_privileges ON tablename TO ...
   GRANT func_privileges ON FUNCTION funcname(...) TO ...

Both table_privileges and func_privileges can be ALL PRIVILEGES.

Attempt 1:

We set up:
   table_privileges = SELECT | UPDATE | ... | ALL PRIVILEGES
   func_privileges = EXECUTE | ALL PRIVILEGES

This yields a reduce/reduce conflict.

The easy fix is not to allow ALL PRIVILEGES in func_privileges because
it's useless as there's only one privilege anyway.  But the problem is
bound to reappear because one day there will be some kind of object that
requires more than one privilege.  Futhermore, it would seem nice for
consistency and for SQL-compliance to allow ALL PRIVILEGES for any kind of
object.

Attempt 2:

We set up
   privileges = SELECT | UPDATE | ... | EXECUTE | ALL PRIVILEGES
   grant_table = GRANT privileges ON tablename TO ...
   grant_func = GRANT privileges ON FUNCTION funcname(...) TO ...

and worry about sorting out the correct privileges for each object
elsewhere.

This leads to a shift/reduce conflict at the state
   GRANT privileges ON FUNCTION

where FUNCTION could be a table name or introducing an actual function
name.

So this option looks like it will require making FUNCTION a reserved word
(ColLabel).

More generally, this approach will require that any word introducing an
object in the grant statement will have to be reserved.  This includes
LANGUAGE, PROCEDURAL, possibly TYPE in the future.

Doing this is consistent with SQL99 but will lead to the usual annoyances.

Any comments?

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> Entertaining parser conflicts again.

I agree with sorting out the privileges lists later.

> Attempt 2:

> We set up

>     privileges = SELECT | UPDATE | ... | EXECUTE | ALL PRIVILEGES

>     grant_table = GRANT privileges ON tablename TO ...

>     grant_func = GRANT privileges ON FUNCTION funcname(...) TO ...

> This leads to a shift/reduce conflict at the state

>     GRANT privileges ON FUNCTION

> where FUNCTION could be a table name or introducing an actual function
> name.

The trick with this sort of problem is to make sure that the parser
doesn't have to reduce anything until it's seen enough tokens to make
the result unambiguous.  You are losing here because the parser has to
decide whether or not to reduce FUNCTION to tablename before it can
see any further than the TO.

I think it might work to do
grant := GRANT privileges ON grant_target TO ...
grant_target := tablename
        | FUNCTION funcname(...)
        regards, tom lane