Обсуждение: Using current_database() in a grant
In 7.3b1 I am trying to use current_database in a grant statement to give access to the current database in a script. Since I really only have one database I plan on using the script for I can just hard code the name. However I would think it would be nice to allow this to work so people can keep their scripts more general without having to do more complicated mechanisms. Here is what happens when I try this: area=# grant create on database current_database() to bruno; ERROR: parser: parse error at or near "(" at character 42
On Sun, Oct 20, 2002 at 10:27:15 -0500, Bruno Wolff III <bruno@wolff.to> wrote: > In 7.3b1 I am trying to use current_database in a grant statement to > give access to the current database in a script. Since I really > only have one database I plan on using the script for I can just > hard code the name. However I would think it would be nice to allow > this to work so people can keep their scripts more general without > having to do more complicated mechanisms. > > Here is what happens when I try this: > area=# grant create on database current_database() to bruno; > ERROR: parser: parse error at or near "(" at character 42 I guess using :DBNAME in psgl is just as easy, but it does seem odd that I can't use the function.
Bruno Wolff III <bruno@wolff.to> writes: > area=# grant create on database current_database() to bruno; > ERROR: parser: parse error at or near "(" at character 42 GRANT, like essentially all other utility statements, only allows simple names and literal constants in its parameters. I'm not excited about trying to generalize that to arbitrary expressions (or even just function calls), for a couple of reasons: * probable syntax problems (shift/reduce conflicts), which could only be resolved by turning lots more keywords into fully-reserved words. The syntax of the utility commands is pretty irregular and involves lots of keywords that don't presently have to be reserved because they're not keywords when used in or near expressions. We'd lose that separation if we allowed expressions in the utility commands. * implementation problems and definitional problems in allowing arbitrary user-defined code to run while a utility command is executed. You can do what you want to do easily enough with a plpgsql function containing an EXECUTE command, so I don't see the need to try to implement it at a lower level ... regards, tom lane