Re: jsonpath - Mailing list pgsql-hackers

From Tom Lane
Subject Re: jsonpath
Date
Msg-id 14890.1555523005@sss.pgh.pa.us
Whole thread Raw
In response to Re: jsonpath  (John Naylor <john.naylor@2ndquadrant.com>)
Responses Re: jsonpath
Re: jsonpath
List pgsql-hackers
John Naylor <john.naylor@2ndquadrant.com> writes:
> Attached is a patch to fix some minor issues:
> -misspelling of an error message

Yeah, I'd noticed that one too :-(.  I think the whole jsonpath patch
needs a sweep to bring its error messages into line with our style
guidelines, but no harm in starting with the obvious bugs.

> -Commit 550b9d26f80f failed to update the Makefile comment to reflect
> how the build changed, and also removed the clean target, which we now
> have use for since we later got rid of backtracking in the scanner.

Right.  I'm not really sure why we're bothering with anti-backtracking
here, or with using speed-rather-than-code-space lexer optimization
options.  It's hard for me to credit that any practically-useful jsonpath
pattern would be long enough for lexer speed to matter, and even harder to
credit that the speed of the flex code itself would be an important factor
in the overall processing cost of a long jsonpath.  Still, as long as we
have the code it needs to be right.

> Also, while I have the thought in my head, for v13 we should consider
> replacing the keyword binary search with the perfect hash technique
> added in c64d0cd5ce2 -- it might give a small performance boost to the
> scanner.

I doubt it's worth the trouble, per above.

Patch LGTM, pushed.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [patch] pg_test_timing does not prompt illegal option
Next
From: Tom Lane
Date:
Subject: Re: New vacuum option to do only freezing