Re: SQL/JSON path issues/questions

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Liudmila Mantrova <l(dot)mantrova(at)postgrespro(dot)ru>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL/JSON path issues/questions
Date: 2019-06-21 17:04:31
Message-ID: CAPpHfds4rCkLbU94jeD9sujUS0fj1hKX8WyTkWQ2Ab7M1bg0aQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 19, 2019 at 10:14 PM Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Keith Fiske 2019-06-21 17:06:19 Re: BUG #15865: ALTER TABLE statements causing "relation already exists" errors when some indexes exist
Previous Message Stephen Frost 2019-06-21 17:01:33 Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions