Parser conflicts in extended GRANT statement

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Parser conflicts in extended GRANT statement
Date: 2002-02-15 23:15:15
Message-ID: Pine.LNX.4.30.0202151757020.681-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)gmx(dot)net

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-02-16 00:09:42 Re: Odd statistics behaviour in 7.2
Previous Message Tom Lane 2002-02-15 22:56:43 Re: Maintaining the list of release changes