Thread: 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