Are there any escaping syntax for psql variable inside PostgreSQL functions?

PSQL SET variables aren't interpolated inside dollar-quoted strings. I don't know this for certain, but I think there's no escape or other trickery to turn on SET variable interpolation in there.

One might think you could wedge an unquoted :user between two dollar-quoted stretches of PL/pgSQL to get the desired effect. But this doesn't seem to work... I think the syntax requires a single string and not an expression concatenating strings. Might be mistaken on that.

Anyway, that doesn't matter. There's another approach (as Pasco noted): write the stored procedure to accept a PL/pgSQL argument. Here's what that would look like.

CREATE OR REPLACE FUNCTION foo("user" TEXT) RETURNS void AS$$BEGIN        EXECUTE 'GRANT SELECT ON my_table TO GROUP ' || quote_ident(user);END;    $$ LANGUAGE plpgsql;

Notes on this function:

1. EXECUTE generates an appropriate GRANT on each invocation using on our procedure argument. The PG manual section called "Executing Dynamic Commands" explains EXECUTE in detail.
2. The declaration of procedure argument user must be double quoted. Double quotes force it to be interpreted as an identifier.

Once you define the function like this, you can call it using interpolated PSQL variables. Here's an outline.

1. Run psql --variable user="'whoever'" --file=myscript.sql. Single quotes are required around the username!
2. In myscript.sql, define function like above.
3. In myscript.sql, put select foo(:user);. This is where we rely on those single quotes we put in the value of user.

Although this seems to work, it strikes me as rather squirrely. I thought SET variables were intended for runtime configuration. Carrying data around in SET seems odd.

Edit: here's a concrete reason to not use SET variables. From the manpage: "These assignments are done during a very early stage of startup, so variables reserved for internal purposes might get overwritten later." If Postgres decided to use a variable named user (or whatever you pick), it could overwrite your script argument with something you never intended. In fact, psql already takes USER for itself -- this only works because SET is case sensitive. This very nearly broke things from the start!

You could use the method Dan LaRocque describes to make it kind of hack'ishly work (not a knock at Dan) - but psql is not really your friend for doing this kind of work (assuming this kind of work is scripting and not one-off things). If you've got a function, rewrite it to take a parameter like so:

create function foo(v_user text) returns void as$$begin    execute 'grant select on my_table to group '||quote_ident(v_user);end;$$language plpgsql;

(quote_ident() makes it so you don't have to assure the double-quotes, it handles all that.)

But then use a real scripting language like Perl, Python, Ruby, etc that has a Postgres driver to invoke your function with a parameter.

Psql has its place, I'm just not sure that this is it.

Actually, in more modern versions of psql there's a way to use psql variables in function bodies, but it's convoluted.

Since the function body has to be a string constant and psql does not perform variable interpolation within string constants we have to resort to assembling the function body in a separate first step:

select format($$begin    grant select on my_table to group %I;end;$$, :'user')as function_body \gset

Note the trailing \gset command which stores the resulting string in the variable function_body.In a second step we can now create the final function:

create function foo() returns void as:'function_body'language plpgsql;