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:

Previous
From: Tom Lane
Date:
Subject: Weird index ordering in psql's \d (was Re: BUG #15865: ALTER TABLE statements causing "relation already exists" errors when some indexes exist)
Next
From: Tom Lane
Date:
Subject: Re: psql UPDATE field [tab] expands to DEFAULT?