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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(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:37:02
Message-ID: CAFj8pRCvrwBs-Uze3nLwMC80zQYXxH5PCiq=ndeCFNukjdgLog@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 30. 11. 2020 v 16:06 odesílatel David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> napsal:

> 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.
>

ok

Pavel

> David J.
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anastasia Lubennikova 2020-11-30 15:37:22 Re: Dumping/restoring fails on inherited generated column
Previous Message Alvaro Herrera 2020-11-30 15:32:43 Re: Improper use about DatumGetInt32