On Thu, 11 Jul 2019 at 16:23, Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > > On Thu, Jul 11, 2019 at 5:10 PM Thom Brown <t...@linux.com> wrote: > > On Wed, 10 Jul 2019 at 05:58, Alexander Korotkov > > <a.korot...@postgrespro.ru> wrote: > > > > > > On Mon, Jul 8, 2019 at 12:30 AM Alexander Korotkov > > > <a.korot...@postgrespro.ru> wrote: > > > > On Thu, Jul 4, 2019 at 4:38 PM Liudmila Mantrova > > > > <l.mantr...@postgrespro.ru> 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