Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs
Date: 2020-11-30 15:06:28
Message-ID: CAKFQuwarwoQKLRUQViY8TnEV1wi=jX2y85SS+3ErEbca9ABfEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 30, 2020 at 12:51 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

>
>
> po 30. 11. 2020 v 4:24 odesílatel David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> napsal:
>
>> On Thu, Nov 26, 2020 at 12:49 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>> wrote:
>>
>>>
>>>
>>> čt 26. 11. 2020 v 6:41 odesílatel David G. Johnston <
>>> david(dot)g(dot)johnston(at)gmail(dot)com> napsal:
>>>
>>>> Hackers,
>>>>
>>>> Bug # 16519 [1] is another report of confusion regarding trying to use
>>>> parameters in improper locations - specifically the SET ROLE command within
>>>> pl/pgsql. I'm re-attaching the doc patch and am adding it to the
>>>> commitfest.
>>>>
>>>
>>> I checked this patch, and I think so it is correct - my comments are
>>> just about enhancing by some examples
>>>
>>>>
>>>>
>> Thank you for the review.
>>
>> v2 attached.
>>
>> I added examples in the two places you noted.
>>
>> Upon re-reading, I decided that opening up the section by including
>> everything then fitting in parameters with an exception for utility
>> commands (without previously/otherwise identifying them) forced some
>> undesirable verbosity. Instead, I opened up with the utility commands as
>> the main body of non-result returning commands and then moved onto
>> delete/insert/update non-returning cases when the subsequent paragraph
>> regarding parameters can then refer to the second class (by way of
>> excluding the first class). This seems to flow better, IMO.
>>
>
> I have no objections, but maybe these pages are a little bit unclear
> generally, because the core of the problem is not described.
>
>

> Personally I miss a description of the reason why variables cannot be used
> - the description "variables cannot be used in statements without result"
> is true, but it is not core information.
>

In the section "executing commands that don't return results" it does seem
like core information...but I get your point.

> The important fact is usage of an execution plan or not.
>

This is already mentioned in the linked-to section:

"Variable substitution currently works only in SELECT, INSERT, UPDATE, and
DELETE commands, because the main SQL engine allows query parameters only
in these commands. To use a non-constant name or value in other statement
types (generically called utility statements), you must construct the
utility statement as a string and EXECUTE it."

I didn't feel the need to repeat that material in full in the "no results"
section. I left that pointing out the "results" dynamic there would be
useful since the original wording seemed to forget about the presence of
utility commands altogether which was confusing for that section.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2020-11-30 15:20:18 Re: [PATCH] Keeps tracking the uniqueness with UniqueKey
Previous Message Peter Eisentraut 2020-11-30 14:50:46 Re: Improper use about DatumGetInt32