@@ -11514,7 +11514,8 @@ table2-mapping
11514
11514
from the JSON data, similar to XPath expressions used
11515
11515
for SQL access to XML. In <productname>PostgreSQL</productname>,
11516
11516
path expressions are implemented as the <type>jsonpath</type>
11517
- data type, described in <xref linkend="datatype-jsonpath"/>.
11517
+ data type and can use any elements described in
11518
+ <xref linkend="datatype-jsonpath"/>.
11518
11519
</para>
11519
11520
11520
11521
<para>JSON query functions and operators
@@ -11561,7 +11562,7 @@ table2-mapping
11561
11562
},
11562
11563
{ "location": [ 47.706, 13.2635 ],
11563
11564
"start time": "2018-10-14 10:39:21",
11564
- "HR": 130
11565
+ "HR": 135
11565
11566
} ]
11566
11567
}
11567
11568
}
@@ -11613,23 +11614,33 @@ table2-mapping
11613
11614
11614
11615
<para>
11615
11616
When defining the path, you can also use one or more
11616
- <firstterm>filter expressions</firstterm>, which work similar to
11617
- the <literal>WHERE</literal> clause in SQL. Each filter expression
11618
- can provide one or more filtering conditions that are applied
11619
- to the result of the path evaluation. Each filter expression must
11620
- be enclosed in parentheses and preceded by a question mark.
11621
- Filter expressions are evaluated from left to right and can be nested.
11622
- The <literal>@</literal> variable denotes the current path evaluation
11623
- result to be filtered, and can be followed by one or more accessor
11624
- operators to define the JSON element by which to filter the result.
11625
- Functions and operators that can be used in the filtering condition
11626
- are listed in <xref linkend="functions-sqljson-filter-ex-table"/>.
11627
- SQL/JSON defines three-valued logic, so the result of the filter
11628
- expression may be <literal>true</literal>, <literal>false</literal>,
11617
+ <firstterm>filter expressions</firstterm> that work similar to the
11618
+ <literal>WHERE</literal> clause in SQL. A filter expression begins with
11619
+ a question mark and provides a condition in parentheses:
11620
+
11621
+ <programlisting>
11622
+ ? (<replaceable>condition</replaceable>)
11623
+ </programlisting>
11624
+ </para>
11625
+
11626
+ <para>
11627
+ Filter expressions must be specified right after the path evaluation step
11628
+ to which they are applied. The result of this step is filtered to include
11629
+ only those items that satisfy the provided condition. SQL/JSON defines
11630
+ three-valued logic, so the condition can be <literal>true</literal>, <literal>false</literal>,
11629
11631
or <literal>unknown</literal>. The <literal>unknown</literal> value
11630
- plays the same role as SQL <literal>NULL</literal>. Further path
11632
+ plays the same role as SQL <literal>NULL</literal> and can be tested
11633
+ for with the <literal>is unknown</literal> predicate. Further path
11631
11634
evaluation steps use only those items for which filter expressions
11632
- return true.
11635
+ return <literal>true</literal>.
11636
+ </para>
11637
+
11638
+ <para>
11639
+ Functions and operators that can be used in filter expressions are listed
11640
+ in <xref linkend="functions-sqljson-filter-ex-table"/>. The path
11641
+ evaluation result to be filtered is denoted by the <literal>@</literal>
11642
+ variable. To refer to a JSON element stored at a lower nesting level,
11643
+ add one or more accessor operators after <literal>@</literal>.
11633
11644
</para>
11634
11645
11635
11646
<para>
@@ -11643,8 +11654,8 @@ table2-mapping
11643
11654
<para>
11644
11655
To get the start time of segments with such values instead, you have to
11645
11656
filter out irrelevant segments before returning the start time, so the
11646
- filter is applied to the previous step and the path in the filtering
11647
- condition is different:
11657
+ filter expression is applied to the previous step, and the path used
11658
+ in the condition is different:
11648
11659
<programlisting>
11649
11660
'$.track.segments[*] ? (@.HR > 130)."start time"'
11650
11661
</programlisting>
@@ -11669,9 +11680,9 @@ table2-mapping
11669
11680
</para>
11670
11681
11671
11682
<para>
11672
- You can also nest filters within each other:
11683
+ You can also nest filter expressions within each other:
11673
11684
<programlisting>
11674
- '$.track ? (@.segments[*] ? (@.HR > 130)).segments.size()'
11685
+ '$.track ? (exists( @.segments[*] ? (@.HR > 130) )).segments.size()'
11675
11686
</programlisting>
11676
11687
This expression returns the size of the track if it contains any
11677
11688
segments with high heart rate values, or an empty sequence otherwise.
@@ -12261,7 +12272,7 @@ table2-mapping
12261
12272
<row>
12262
12273
<entry><literal>@?</literal></entry>
12263
12274
<entry><type>jsonpath</type></entry>
12264
- <entry>Does JSON path returns any item for the specified JSON value?</entry>
12275
+ <entry>Does JSON path return any item for the specified JSON value?</entry>
12265
12276
<entry><literal>'{"a":[1,2,3,4,5]}'::jsonb @? '$.a[*] ? (@ > 2)'</literal></entry>
12266
12277
</row>
12267
12278
<row>
@@ -12289,8 +12300,8 @@ table2-mapping
12289
12300
<note>
12290
12301
<para>
12291
12302
The <literal>@?</literal> and <literal>@@</literal> operators suppress
12292
- errors including : lacking object field or array element, unexpected JSON
12293
- item type and numeric errors.
12303
+ the following errors : lacking object field or array element, unexpected
12304
+ JSON item type, and numeric errors.
12294
12305
This behavior might be helpful while searching over JSON document
12295
12306
collections of varying structure.
12296
12307
</para>
@@ -13146,17 +13157,17 @@ table2-mapping
13146
13157
<literal>jsonb_path_query</literal>, <literal>jsonb_path_query_array</literal> and
13147
13158
<literal>jsonb_path_query_first</literal>
13148
13159
functions have optional <literal>vars</literal> and <literal>silent</literal>
13149
- argument .
13160
+ arguments .
13150
13161
</para>
13151
13162
<para>
13152
- When <literal>vars</literal> argument is specified, it constitutes an object
13153
- contained variables to be substituted into <literal>jsonpath</literal>
13154
- expression.
13163
+ If the <literal>vars</literal> argument is specified, it provides an
13164
+ object containing named variables to be substituted into a
13165
+ <literal>jsonpath</literal> expression.
13155
13166
</para>
13156
13167
<para>
13157
- When <literal>silent</literal> argument is specified and has
13158
- <literal>true</literal> value, the same errors are suppressed as it is in
13159
- the <literal>@?</literal> and <literal>@@</literal> operators.
13168
+ If the <literal>silent</literal> argument is specified and has the
13169
+ <literal>true</literal> value, these functions suppress the same errors
13170
+ as the <literal>@?</literal> and <literal>@@</literal> operators.
13160
13171
</para>
13161
13172
</note>
13162
13173
0 commit comments