Re: BUG #16519: SET SESSION ROLE in plpgsql requires string literal.

I've moved this over to -hackers and the commitfest.

https://www.postgresql.org/message-id/CAKFQuwYvMKucM5fnZvHSo-ah4S%3D_n9gmKeu6EAo%3D_fTrohunqQ%40mail.gmail.com

David J.

On Fri, Oct 2, 2020 at 1:11 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Tue, Jun 30, 2020 at 10:50 AM David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>> On Tuesday, June 30, 2020, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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
>>
>>
> Concretely, as attached.
>
> I found the comment about the 9.0 behavior to be unnecessary at this point
> and so removed it.
>
> The wording in the PL/SQL conversion comments is a bit out-of-scope but
> took a look at it too as it also redirects the user to the variable
> discussion and I looked at all 4 cross-references.
>
> David J.
>
>