Re: jsonpath

On Fri, Mar 29, 2019 at 4:15 PM Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> On Thu, Mar 28, 2019 at 7:43 PM Andrew Dunstan
> <andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
> > On 3/28/19 9:50 AM, Tom Lane wrote:
> > > Andres Freund <andres(at)anarazel(dot)de> writes:
> > >> On March 28, 2019 9:31:14 AM EDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >>> Has anybody gotten through a valgrind run on this code yet?
> > >> Skink has successfully passed since - but that's x86...
> > > Yeah, there is a depressingly high chance that this is somehow specific
> > > to the bison version, flex version, and/or compiler in use on jacana.
> >
> > lousyjack has also passed it (x64).
> >
> > git bisect on jacana blames commit 550b9d26f.
>
> Hmm... 550b9d26f just makes jsonpath_gram.y and jsonpath_scan.l
> compile at once. I've re-read this commit and didn't find anything
> suspicious.
> I've asked Andrew for access to jacana in order to investigate this myself.

I'm going to push there 3 attached patches for jsonpath.

1st one is revised patch implementing GIN index support for jsonpath.
Based on feedback from Jonathan Katz, I decided to restrict jsonb_ops
from querying only case. Now, jsonb_ops also works on if
"accessors_chain = const" statement is found. Keys are frequently not
selective. Given we have no statistics of them, purely key GIN
queries are likely confuse optimizer making it select inefficient
plan. Actually, jsonb_ops may be used for pure key query when ?
operator is used. But in this case, user explicitly searches for key.
With jsonpath, purely key GIN searches can easily happen unintended.
So, restrict that.

2nd and 3rd patches are from Nikita Glukhov upthread. 2nd restrict
some cases in parsing numerics. 3rd make jsonb_path_match() function
throw error when result is not single boolean and silent mode is off.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company