Assorted fixes for jsonpath documentation

This commit contains assorted fixes for jsonpath documentation including:
grammar fixes, incorrect examples fixes as well as wording improvements.

Discussion: https://postgr.es/m/CAA-aLv4VVX%3Db9RK5hkfPXJczqaiTdqO04teW9i0wiQVhdKcqzw%40mail.gmail.com
Author: Liudmila Mantrova
Reviewed-by: Alexander Korotkov
Reported-by: Thom Brown
Backpatch-through: 12

doc/src/sgml/func.sgml

@@ -11538,7 +11538,8 @@ table2-mapping
    from the JSON data, similar to XPath expressions used
    for SQL access to XML. In <productname>PostgreSQL</productname>,
    path expressions are implemented as the <type>jsonpath</type>
-   data type, described in <xref linkend="datatype-jsonpath"/>.
+   data type and can use any elements described in
+   <xref linkend="datatype-jsonpath"/>.
   </para>
 
   <para>JSON query functions and operators
@@ -11585,7 +11586,7 @@ table2-mapping
       },
       { "location":   [ 47.706, 13.2635 ],
         "start time": "2018-10-14 10:39:21",
-        "HR": 130
+        "HR": 135
       } ]
   }
 }
@@ -11637,23 +11638,33 @@ table2-mapping
 
   <para>
    When defining the path, you can also use one or more
-   <firstterm>filter expressions</firstterm>, which work similar to
+   <firstterm>filter expressions</firstterm> that work similar to the
-   the <literal>WHERE</literal> clause in SQL. Each filter expression
+   <literal>WHERE</literal> clause in SQL. A filter expression begins with
-   can provide one or more filtering conditions that are applied
+   a question mark and provides a condition in parentheses:
-   to the result of the path evaluation. Each filter expression must
+
-   be enclosed in parentheses and preceded by a question mark.
+    <programlisting>
-   Filter expressions are evaluated from left to right and can be nested.
+? (<replaceable>condition</replaceable>)
-   The <literal>@</literal> variable denotes the current path evaluation
+    </programlisting>
-   result to be filtered, and can be followed by one or more accessor
+  </para>
-   operators to define the JSON element by which to filter the result.
+
-   Functions and operators that can be used in the filtering condition
+  <para>
-   are listed in <xref linkend="functions-sqljson-filter-ex-table"/>.
+   Filter expressions must be specified right after the path evaluation step
-   SQL/JSON defines three-valued logic, so the result of the filter
+   to which they are applied. The result of this step is filtered to include
-   expression may be <literal>true</literal>, <literal>false</literal>,
+   only those items that satisfy the provided condition. SQL/JSON defines
+   three-valued logic, so the condition can be <literal>true</literal>, <literal>false</literal>,
    or <literal>unknown</literal>. The <literal>unknown</literal> value
-   plays the same role as SQL <literal>NULL</literal>. Further path
+   plays the same role as SQL <literal>NULL</literal> and can be tested
+   for with the <literal>is unknown</literal> predicate. Further path
    evaluation steps use only those items for which filter expressions
-   return true.
+   return <literal>true</literal>.
+  </para>
+
+  <para>
+   Functions and operators that can be used in filter expressions are listed
+   in <xref linkend="functions-sqljson-filter-ex-table"/>. The path
+   evaluation result to be filtered is denoted by the <literal>@</literal>
+   variable. To refer to a JSON element stored at a lower nesting level,
+   add one or more accessor operators after <literal>@</literal>.
   </para>
 
   <para>
@@ -11667,8 +11678,8 @@ table2-mapping
   <para>
    To get the start time of segments with such values instead, you have to
    filter out irrelevant segments before returning the start time, so the
-   filter is applied to the previous step and the path in the filtering
+   filter expression is applied to the previous step, and the path used
-   condition is different:
+   in the condition is different:
 <programlisting>
 '$.track.segments[*] ? (@.HR &gt; 130)."start time"'
 </programlisting>
@@ -11693,9 +11704,9 @@ table2-mapping
   </para>
 
   <para>
-   You can also nest filters within each other:
+   You can also nest filter expressions within each other:
 <programlisting>
-'$.track ? (@.segments[*] ? (@.HR &gt; 130)).segments.size()'
+'$.track ? (exists(@.segments[*] ? (@.HR &gt; 130))).segments.size()'
 </programlisting>
    This expression returns the size of the track if it contains any
    segments with high heart rate values, or an empty sequence otherwise.
@@ -12285,7 +12296,7 @@ table2-mapping
        <row>
         <entry><literal>@?</literal></entry>
         <entry><type>jsonpath</type></entry>
-        <entry>Does JSON path returns any item for the specified JSON value?</entry>
+        <entry>Does JSON path return any item for the specified JSON value?</entry>
         <entry><literal>'{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] ? (@ > 2)'</literal></entry>
        </row>
        <row>
@@ -12313,8 +12324,8 @@ table2-mapping
   <note>
    <para>
     The <literal>@?</literal> and <literal>@@</literal> operators suppress
-    errors including: lacking object field or array element, unexpected JSON
+    the following errors: lacking object field or array element, unexpected
-    item type and numeric errors.
+    JSON item type, and numeric errors.
     This behavior might be helpful while searching over JSON document
     collections of varying structure.
    </para>
@@ -13170,17 +13181,17 @@ table2-mapping
     <literal>jsonb_path_query</literal>, <literal>jsonb_path_query_array</literal> and
     <literal>jsonb_path_query_first</literal>
     functions have optional <literal>vars</literal> and <literal>silent</literal>
-    argument.
+    arguments.
    </para>
    <para>
-    When <literal>vars</literal> argument is specified, it constitutes an object
+    If the <literal>vars</literal> argument is specified, it provides an
-    contained variables to be substituted into <literal>jsonpath</literal>
+    object containing named variables to be substituted into a
-    expression.
+    <literal>jsonpath</literal> expression.
    </para>
    <para>
-    When <literal>silent</literal> argument is specified and has
+    If the <literal>silent</literal> argument is specified and has the
-    <literal>true</literal> value, the same errors are suppressed as it is in
+    <literal>true</literal> value, these functions suppress the same errors
-    the <literal>@?</literal> and <literal>@@</literal> operators.
+    as the <literal>@?</literal> and <literal>@@</literal> operators.
    </para>
   </note>
 

doc/src/sgml/json.sgml

@@ -815,21 +815,18 @@ SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @> '{"tags": ["qu
         <literal>.**{<replaceable>level</replaceable>}</literal>
        </para>
        <para>
-        <literal>.**{<replaceable>lower_level</replaceable> to
+        <literal>.**{<replaceable>start_level</replaceable> to
-        <replaceable>upper_level</replaceable>}</literal>
+        <replaceable>end_level</replaceable>}</literal>
-       </para>
-       <para>
-        <literal>.**{<replaceable>lower_level</replaceable> to
-        last}</literal>
        </para>
       </entry>
       <entry>
        <para>
-        Same as <literal>.**</literal>, but with filter over nesting
+        Same as <literal>.**</literal>, but with a filter over nesting
-        level of JSON hierarchy.  Levels are specified as integers.
+        levels of JSON hierarchy. Nesting levels are specified as integers.
-        Zero level corresponds to current object.  This is a
+        Zero level corresponds to the current object. To access the lowest
-        <productname>PostgreSQL</productname> extension of the SQL/JSON
+        nesting level, you can use the <literal>last</literal> keyword.
-        standard.
+        This is a <productname>PostgreSQL</productname> extension of
+        the SQL/JSON standard.
        </para>
       </entry>
      </row>
@@ -841,19 +838,22 @@ SELECT jdoc-&gt;'guid', jdoc-&gt;'name' FROM api WHERE jdoc @&gt; '{"tags": ["qu
       </entry>
       <entry>
        <para>
-        Array element accessor.  <literal><replaceable>subscript</replaceable></literal>
+        Array element accessor.
-        might be given in two forms: <literal><replaceable>expr</replaceable></literal>
+        <literal><replaceable>subscript</replaceable></literal> can be
-        or <literal><replaceable>lower_expr</replaceable> to <replaceable>upper_expr</replaceable></literal>.
+        given in two forms: <literal><replaceable>index</replaceable></literal>
-        The first form specifies single array element by its index.  The second
+        or <literal><replaceable>start_index</replaceable> to <replaceable>end_index</replaceable></literal>.
-        form specified array slice by the range of indexes.  Zero index
+        The first form returns a single array element by its index. The second
-        corresponds to the first array element.
+        form returns an array slice by the range of indexes, including the
+        elements that correspond to the provided
+        <replaceable>start_index</replaceable> and <replaceable>end_index</replaceable>.
        </para>
        <para>
-        An expression in the subscript may be an integer,
+        The specified <replaceable>index</replaceable> can be an integer, as
-        numeric expression, or any other <literal>jsonpath</literal> expression
+        well as an expression returning a single numeric value, which is
-        returning single numeric value.  The <literal>last</literal> keyword
+        automatically cast to integer. Zero index corresponds to the first
-        can be used in the expression denoting the last subscript in an array.
+        array element. You can also use the <literal>last</literal> keyword
-        That's helpful for handling arrays of unknown length.
+        to denote the last array element, which is useful for handling arrays
+        of unknown length.
        </para>
       </entry>
      </row>