On Thu, 11 Jul 2019 at 16:23, Alexander Korotkov
<[email protected]> wrote:
>
> On Thu, Jul 11, 2019 at 5:10 PM Thom Brown <[email protected]> wrote:
> > On Wed, 10 Jul 2019 at 05:58, Alexander Korotkov
> > <[email protected]> wrote:
> > >
> > > On Mon, Jul 8, 2019 at 12:30 AM Alexander Korotkov
> > > <[email protected]> wrote:
> > > > On Thu, Jul 4, 2019 at 4:38 PM Liudmila Mantrova
> > > > <[email protected]> wrote:
> > > > > Thank you!
> > > > >
> > > > > I think we can make this sentence even shorter, the fix is attached:
> > > > >
> > > > > "To refer to a JSON element stored at a lower nesting level, add one
> > > > > or
> > > > > more accessor operators after <literal>@</literal>."
> > > >
> > > > Thanks, looks good to me. Attached revision of patch contains commit
> > > > message. I'm going to commit this on no objections.
> > >
> > > So, pushed!
> >
> > I've just noticed the >= operator shows up as just > in the "jsonpath
> > Filter Expression Elements" table, and the <= example only shows <.
>
> Thank you for catching this! Fix just pushed.
Thanks.
Now I'm looking at the @? and @@ operators, and getting a bit
confused. This following query returns true, but I can't determine
why:
# SELECT '{"a":[1,2,3,4,5]}'::jsonb @? '$.b == "hello"'::jsonpath;
?column?
----------
t
(1 row)
"b" is not a valid item, so there should be no match. Perhaps it's my
misunderstanding of how these operators are supposed to work, but the
documentation is quite terse on the behaviour.
Thom
