Re: SQL/JSON path issues/questions
Thom Brown <thom@linux.com>
From: Thom Brown <thom@linux.com>
To: Alexander Korotkov <a.korotkov@postgrespro.ru>
Cc: Liudmila Mantrova <l.mantrova@postgrespro.ru>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-07-11T14:09:28Z
Lists: pgsql-hackers
On Wed, 10 Jul 2019 at 05:58, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote: > > On Mon, Jul 8, 2019 at 12:30 AM Alexander Korotkov > <a.korotkov@postgrespro.ru> wrote: > > On Thu, Jul 4, 2019 at 4:38 PM Liudmila Mantrova > > <l.mantrova@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 <. Thom
Commits
-
Fixes for jsonpath filter expression elements table in docs
- 1ed89826b82c 12.0 landed
- 0cea6eb5a5f2 13.0 landed
-
Assorted fixes for jsonpath documentation
- a5c2f3a346fc 12.0 landed
- 5a7d697a3936 13.0 landed
-
Fix description for $varname jsonpath variable
- dfd79e2d0e8f 12.0 landed
-
Improve documentation for jsonpath like_regex predicate
- 1ff8dc9f19dd 12.0 landed
-
Support 'q' flag in jsonpath 'like_regex' predicate
- 261a5c192856 12.0 landed