Re: SQL/JSON path issues/questions - Mailing list pgsql-hackers
From | Liudmila Mantrova |
---|---|
Subject | Re: SQL/JSON path issues/questions |
Date | |
Msg-id | 148b20c5-252e-5f78-0daa-dfc54b898bc9@postgrespro.ru Whole thread Raw |
In response to | Re: SQL/JSON path issues/questions (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Responses |
Re: SQL/JSON path issues/questions
|
List | pgsql-hackers |
On 6/21/19 8:04 PM, Alexander Korotkov wrote: > On Wed, Jun 19, 2019 at 10:14 PM Alexander Korotkov > <a.korotkov@postgrespro.ru> wrote: >>> While I have no objections to the proposed fixes, I think we can further >>> improve patch 0003 and the text it refers to. >>> In attempt to clarify jsonpath docs and address the concern that ? is >>> hard to trace in the current text, I'd also like to propose patch 0004. >>> Please see both of them attached. >> Thank you for your editing. I'm going to commit them as well. >> >> But I'm going to commit your changes separately from 0003 I've posted >> before. Because 0003 fixes factual error, while you're proposing set >> of grammar/style fixes. > I made some review of these patches. My notes are following: > > <para> > - See also <xref linkend="functions-aggregate"/> for the aggregate > - function <function>json_agg</function> which aggregates record > - values as JSON, and the aggregate function > - <function>json_object_agg</function> which aggregates pairs of values > - into a JSON object, and their <type>jsonb</type> equivalents, > + See also <xref linkend="functions-aggregate"/> for details on > + <function>json_agg</function> function that aggregates record > + values as JSON, <function>json_object_agg</function> function > + that aggregates pairs of values into a JSON object, and their > <type>jsonb</type> equivalents, > <function>jsonb_agg</function> and <function>jsonb_object_agg</function>. > </para> > > This part is not directly related to jsonpath, and it has been there > for a long time. I'd like some native english speaker to review this > change before committing this. > > <para> > - Expression inside subscript may consititue an integer, > - numeric expression or any other <literal>jsonpath</literal> expression > - returning single numeric value. The <literal>last</literal> keyword > - can be used in the expression denoting the last subscript in an array. > - That's helpful for handling arrays of unknown length. > + The specified <replaceable>index</replaceable> can be an integer, > + as well as a numeric or <literal>jsonpath</literal> expression that > + returns a single integer value. Zero index corresponds to the first > + array element. To access the last element in an array, you can use > + the <literal>last</literal> keyword, which is useful for handling > + arrays of unknown length. > </para> > > I think this part requires more work. Let's see what cases do we have > with examples: > > 1) Integer: '$.ar[1]' > 2) Numeric: '$.ar[1.5]' (converted to integer) > 3) Some numeric expression: '$.ar[last - 1]' > 4) Arbitrary jsonpath expression: '$.ar[$.ar2.size() + $.num - 2]' > > In principle, it not necessary to divide 3 and 4, or divide 1 and 2. > Or we may don't describe cases at all, but just say it's a jsonpath > expression returning numeric, which is converted to integer. > > Also, note that we do not necessary *access* last array element with > "last" keyword. "last" keyword denotes index of last element in > expression. But completely different element might be actually > accessed. > > ------ > Alexander Korotkov > Postgres Professional: http://www.postgrespro.com > The Russian Postgres Company > Hi Alexander, Thank you for the catch! Please see the modified version of patch 0004 attached. As for your comment on patch 0003, since I'm not a native speaker, I can only refer to a recent discussion in pgsql-docs mailing list that seems to support my view on a similar issue: https://www.postgresql.org/message-id/9484.1558050957%40sss.pgh.pa.us -- Liudmila Mantrova Technical writer at Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Attachment
pgsql-hackers by date: