Re: JSON doc example (matchiness)

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Erik Rijkers <er(at)xs4all(dot)nl>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: JSON doc example (matchiness)
Date: 2021-05-09 01:01:47
Message-ID: CAPpHfdubJvaRLXjfeU29Tp55M0L9AQk3sdsA144=-tWKqjQZig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 8, 2021 at 7:09 PM Erik Rijkers <er(at)xs4all(dot)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

Attachment Content-Type Size
doc_jsonpath_like_regex_example.patch application/octet-stream 736 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2021-05-09 04:07:27 Re: plan with result cache is very slow when work_mem is not enough
Previous Message David Rowley 2021-05-09 01:01:12 Re: plan with result cache is very slow when work_mem is not enough