Parser conflicts in extended GRANT statement
От | Peter Eisentraut |
---|---|
Тема | Parser conflicts in extended GRANT statement |
Дата | |
Msg-id | Pine.LNX.4.30.0202151757020.681-100000@peter.localdomain обсуждение исходный текст |
Ответы |
Re: Parser conflicts in extended GRANT statement
|
Список | 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@gmx.net
В списке pgsql-hackers по дате отправления: