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