Re: BUG #16519: SET SESSION ROLE in plpgsql requires string literal. - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: BUG #16519: SET SESSION ROLE in plpgsql requires string literal.
Date
Msg-id CAKFQuwbgKpR6TN3xnxsE2k4Zdkb81C-Sv7UMZUxK=O7TTHULCA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16519: SET SESSION ROLE in plpgsql requires string literal.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #16519: SET SESSION ROLE in plpgsql requires string literal.
Re: BUG #16519: SET SESSION ROLE in plpgsql requires string literal.
List pgsql-bugs
On Tuesday, June 30, 2020, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> The SET command cannot be parameterized so using variables in the statement
> is not supported and the attempt to do so is treated as writing an
> identifier.  You will need to use the format function and the execute
> plpgsql command to create and execute the statement.

While this is documented (last para of "42.11.1. Variable Substitution"),
it's not exactly prominent.  Should we move that to somewhere more
visible?  If so where?

I think the docs are acceptable as-is - especially given the numerous cross-references to that section.  If anything i’d maybe call out that most non-result returning commands are actually not parameterized in “42.2.5 Executing a Command with No Result” just before the link to 42.11.1

David J.

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #16520: Deleting from non-existent column in CTE removes all rows
Next
From: Michael Meskes
Date:
Subject: Re: [BUG][PATCH] ecpg crash with bytea type and cursors