JSON doc example (matchiness)
The JSON doc has this example (to show the need for double backslash):
$ ? (@ like_regex "^\\d+$")
The example is not wrong exactly, and can be cast to jsonpath, but as-is
can never match anything.
I think it'd be helpful to provide that example so that it more probably
matches when the user does a quick trial.
Llet's change it to something like:
$.* ? (@ like_regex "^\\d+$")
Patch attached.
thanks,
Erik Rijkers
Attachments:
func.sgml.20210507.difftext/x-patch; charset=UTF-8; name=func.sgml.20210507.diffDownload
--- ./doc/src/sgml/func.sgml.orig 2021-05-07 21:52:53.577952054 +0200
+++ ./doc/src/sgml/func.sgml 2021-05-07 21:53:33.078578522 +0200
@@ -17132,7 +17132,7 @@
backslashes you want to use in the regular expression must be doubled.
For example, to match strings that contain only digits:
<programlisting>
-$ ? (@ like_regex "^\\d+$")
+$.* ? (@ like_regex "^\\d+$")
</programlisting>
</para>
</sect3>
On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
The JSON doc has this example (to show the need for double backslash):
$ ? (@ like_regex "^\\d+$")
The example is not wrong exactly, and can be cast to jsonpath, but as-is can
never match anything.I think it'd be helpful to provide that example so that it more probably
matches when the user does a quick trial.Llet's change it to something like:
$.* ? (@ like_regex "^\\d+$")
Ah, I see. What you are telling here is that we match the regex on
the full JSON string, which is pretty useless, and you are suggesting
to change things so as we'd match with the key names at the first
level. Makes sense.
This paragraph of the docs say:
"For example, to match strings that contain only digits"
Could we be more precise here? "strings" looks to much generic to
me in this context when actually referring to a set of path of keys in
a JSON blob.
--
Michael
On 5/8/21 3:48 AM, Michael Paquier wrote:
On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
The JSON doc has this example (to show the need for double backslash):
$ ? (@ like_regex "^\\d+$")
The example is not wrong exactly, and can be cast to jsonpath, but as-is can
never match anything.I think it'd be helpful to provide that example so that it more probably
matches when the user does a quick trial.Llet's change it to something like:
$.* ? (@ like_regex "^\\d+$")
Ah, I see. What you are telling here is that we match the regex on
the full JSON string, which is pretty useless, and you are suggesting
to change things so as we'd match with the key names at the first
level. Makes sense.This paragraph of the docs say:
"For example, to match strings that contain only digits"
Could we be more precise here? "strings" looks to much generic to
me in this context when actually referring to a set of path of keys in
a JSON blob.
Yes, "string values"� is probably another small improvement.
Show quoted text
--
Michael
On Sat, May 8, 2021 at 7:09 PM Erik Rijkers <er@xs4all.nl> wrote:
On 5/8/21 3:48 AM, Michael Paquier wrote:
On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
The JSON doc has this example (to show the need for double backslash):
$ ? (@ like_regex "^\\d+$")
The example is not wrong exactly, and can be cast to jsonpath, but as-is can
never match anything.I think it'd be helpful to provide that example so that it more probably
matches when the user does a quick trial.Llet's change it to something like:
$.* ? (@ like_regex "^\\d+$")
Ah, I see. What you are telling here is that we match the regex on
the full JSON string, which is pretty useless, and you are suggesting
to change things so as we'd match with the key names at the first
level. Makes sense.This paragraph of the docs say:
"For example, to match strings that contain only digits"
Could we be more precise here? "strings" looks to much generic to
me in this context when actually referring to a set of path of keys in
a JSON blob.Yes, "string values" is probably another small improvement.
What about the attached patch? Wording "string values of the root
object" seems most precise to me.
------
Regards,
Alexander Korotkov
Attachments:
doc_jsonpath_like_regex_example.patchapplication/octet-stream; name=doc_jsonpath_like_regex_example.patchDownload
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 5ae8abff0ce..320862de600 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17129,9 +17129,10 @@ $[*] ? (@ like_regex "^[aeiou]" flag "i")
is a JSON path string literal, written according to the rules given in
<xref linkend="datatype-jsonpath"/>. This means in particular that any
backslashes you want to use in the regular expression must be doubled.
- For example, to match strings that contain only digits:
+ For example, to match string values of the root document that contain
+ only digits:
<programlisting>
-$ ? (@ like_regex "^\\d+$")
+$.* ? (@ like_regex "^\\d+$")
</programlisting>
</para>
</sect3>
On Sun, May 9, 2021 at 4:01 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
On Sat, May 8, 2021 at 7:09 PM Erik Rijkers <er@xs4all.nl> wrote:
On 5/8/21 3:48 AM, Michael Paquier wrote:
On Fri, May 07, 2021 at 10:18:44PM +0200, Erik Rijkers wrote:
The JSON doc has this example (to show the need for double backslash):
$ ? (@ like_regex "^\\d+$")
The example is not wrong exactly, and can be cast to jsonpath, but as-is can
never match anything.I think it'd be helpful to provide that example so that it more probably
matches when the user does a quick trial.Llet's change it to something like:
$.* ? (@ like_regex "^\\d+$")
Ah, I see. What you are telling here is that we match the regex on
the full JSON string, which is pretty useless, and you are suggesting
to change things so as we'd match with the key names at the first
level. Makes sense.This paragraph of the docs say:
"For example, to match strings that contain only digits"
Could we be more precise here? "strings" looks to much generic to
me in this context when actually referring to a set of path of keys in
a JSON blob.Yes, "string values" is probably another small improvement.
What about the attached patch? Wording "string values of the root
object" seems most precise to me.
I propose backpatching this to 12 when jsonpath was introduced. It
seems useful to have this docs improvement every release supporting
jsonpath.
Objections?
------
Regards,
Alexander Korotkov
On Sun, May 09, 2021 at 11:17:47PM +0300, Alexander Korotkov wrote:
I propose backpatching this to 12 when jsonpath was introduced. It
seems useful to have this docs improvement every release supporting
jsonpath.Objections?
None. Backpatching that is a good idea, and your suggested rewording
is an improvement.
--
Michael
On Mon, May 10, 2021 at 3:41 AM Michael Paquier <michael@paquier.xyz> wrote:
On Sun, May 09, 2021 at 11:17:47PM +0300, Alexander Korotkov wrote:
I propose backpatching this to 12 when jsonpath was introduced. It
seems useful to have this docs improvement every release supporting
jsonpath.Objections?
None. Backpatching that is a good idea, and your suggested rewording
is an improvement.
Pushed, thanks!
------
Regards,
Alexander Korotkov