Hi Amit and Andrew,
Regarding not squashing [PATCH v3 11/11] Proposed reworking of
SQL/JSON documentaion, here is exactly what Tom Lane wrote in the comment to commit 47046763c3:
Use <parameter>
consistently for things that are in fact names of parameters (including
OUT parameters), reserving <replaceable> for things that aren't.
Following this, <parameter> tags should be replaced with <replaceable> because
the SQL/JSON functions' code does not explicitly specify those tagged variables
as function parameters. Doesn't it convince you to look at the patch again? Thank you.
On 20.02.2023 10:35, Amit Langote wrote:
>> no parameter names in the functions' code either
> Hi,
>
> On Mon, Jan 30, 2023 at 3:39 PM Amit Langote <amitlangote09@gmail.com> wrote:
>> On Fri, Jan 27, 2023 at 11:27 PM vignesh C <vignesh21@gmail.com> wrote:
>>> On Tue, 17 Jan 2023 at 19:01, Amit Langote <amitlangote09@gmail.com> wrote:
>>>> And I've just finished doing that. In the attached updated 0004,
>>>> which adds the JsonExpr node, its evaluation code is now broken into
>>>> ExprEvalSteps to handle the subsidiary JsonCoercion and JsonBehavior
>>>> expression nodes that previously used ExprState for recursive
>>>> evaluation. Andres didn't like the latter as previously discussed at
>>>> [1].
>>>>
>>>> I've also attached the patch that Elena has proposed as the patch
>>>> 0011. I haven't managed to review it yet, though once I do, I'll
>>>> merge it into the main documentation patch 0009. Thanks Elena.
>>> The patch does not apply on top of HEAD as in [1], please post a rebased patch:
>> Thanks for the heads up. Here's a rebased version.
> Rebased again over queryjumble overhaul.
>
> I decided to squash what was "[PATCH v3 01/11] Common SQL/JSON
> clauses" into "[PATCH v3 02/11] SQL/JSON constructors", because I
> noticed "useless productions" warnings against its gram.y additions
> when building just 0001.
>
> I also looked at squashing "[PATCH v3 11/11] Proposed reworking of
> SQL/JSON documentaion" into "[PATCH v3 09/11] Documentation for
> SQL/JSON features", but didn't, again, because I am still not sure
> which one of <parameter> and <replaceable> is correct for the SQL/JSON
> function constructs. Maybe it's the latter looking at the markup for
> some text on [1], such as exists ( path_expression ) → boolean, but
> Andrew sounded doubtful about that upthread.
>