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 <amitlangot...@gmail.com> wrote:
On Fri, Jan 27, 2023 at 11:27 PM vignesh C <vignes...@gmail.com> wrote:
On Tue, 17 Jan 2023 at 19:01, Amit Langote <amitlangot...@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.
