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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: BUG #16519: SET SESSION ROLE in plpgsql requires string literal.
Дата
Msg-id CAKFQuwZLGL8Fn+S+vsMFMk-kBXLRL9=ctSnomZ63_LYG_cUK5Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #16519: SET SESSION ROLE in plpgsql requires string literal.  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-bugs
I've moved this over to -hackers and the commitfest.


David J.


On Fri, Oct 2, 2020 at 1:11 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Tue, Jun 30, 2020 at 10:50 AM David G. Johnston <david.g.johnston@gmail.com> wrote:
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


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.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #16680: Crash database with sefault 11
Следующее
От: David Christensen
Дата:
Сообщение: Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return