Re: Patch: Improve Boolean Predicate JSON Path Docs - Mailing list pgsql-hackers
| From | David E. Wheeler |
|---|---|
| Subject | Re: Patch: Improve Boolean Predicate JSON Path Docs |
| Date | |
| Msg-id | 005D047C-7C5F-4438-B852-3D20E187A8BE@justatheory.com Whole thread Raw |
| In response to | Re: Re: Patch: Improve Boolean Predicate JSON Path Docs (Erik Wienhold <ewie@ewie.name>) |
| Responses |
Re: Patch: Improve Boolean Predicate JSON Path Docs
|
| List | pgsql-hackers |
On Jan 19, 2024, at 21:46, Erik Wienhold <ewie@ewie.name> wrote:
> Interesting... copy-pasting the entire \set command works for me with
> psql 16.1 in gnome-terminal and tmux. Typing it out manually gives me
> the "unterminated quoted string" error. Maybe has to do with my stty
> settings.
Yes, same on macOS Terminal.app and 16.1 compiled with readline. I didn’t realize that \set didn’t support newlines,
becauseit works fine when you paste something with newlines. Curious.
>> I experimented with
>>
>> SELECT '
>> ... multiline json value ...
>> ' AS json
>> \gexec
>>
>> but that didn't seem to work either. Anybody have a better idea?
>
> Fine with me (the \gset variant).
Much cleaner TBH.
david=# select '{
"track": {
"segments": [
{
"location": [ 47.763, 13.4034 ],
"start time": "2018-10-14 10:05:14",
"HR": 73
},
{
"location": [ 47.706, 13.2635 ],
"start time": "2018-10-14 10:39:21",
"HR": 135
}
]
}
}'::jsonb as json;
json
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{"track": {"segments": [{"HR": 73, "location": [47.763, 13.4034], "start time": "2018-10-14 10:05:14"}, {"HR": 135,
"location":[47.706, 13.2635], "start time": "2018-10-14 10:39:21"}]}}
(1 row)
david=# \gset
david=# select :'json'::jsonb;
jsonb
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{"track": {"segments": [{"HR": 73, "location": [47.763, 13.4034], "start time": "2018-10-14 10:05:14"}, {"HR": 135,
"location":[47.706, 13.2635], "start time": "2018-10-14 10:39:21"}]}}
(1 row)
So great!
While you’re in there, Tom, would it make sense to fold in something like [this patch][1] I posted last month to
clarifywhich JSONPath comparison operators can take advantage of a index?
--- a/doc/src/sgml/json.sgml
+++ b/doc/src/sgml/json.sgml
@@ -513,7 +513,7 @@ SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @@ '$.tags[*] == "qui"';
</programlisting>
For these operators, a GIN index extracts clauses of the form
<literal><replaceable>accessors_chain</replaceable>
- = <replaceable>constant</replaceable></literal> out of
+ == <replaceable>constant</replaceable></literal> out of
the <type>jsonpath</type> pattern, and does the index search based on
the keys and values mentioned in these clauses. The accessors chain
may include <literal>.<replaceable>key</replaceable></literal>,
@@ -522,6 +522,9 @@ SELECT jdoc->'guid', jdoc->'name' FROM api WHERE jdoc @@ '$.tags[*] == "qui"';
The <literal>jsonb_ops</literal> operator class also
supports <literal>.*</literal> and <literal>.**</literal> accessors,
but the <literal>jsonb_path_ops</literal> operator class does not.
+ Only the <literal>==</literal> and <literal>!=</literal> <link
+ linkend="functions-sqljson-path-operators">SQL/JSON Path Operators</link>
+ can use the index.
</para>
<para>
Best,
David
[1]: https://www.postgresql.org/message-id/0ECE6B9C-CDDE-4B65-BE5A-49D7372046AF@justatheory.com
pgsql-hackers by date: