pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Naylor <john.naylor@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: jsonpath
Date: Wed, 17 Apr 2019 13:43:25 -0400
Message-ID: <14890.1555523005@sss.pgh.pa.us> (raw)
In-Reply-To: <CACPNZCt5B8jDCCGQiFoSuqmg-za_NCy4QDioBTLaNRih9+-bXg@mail.gmail.com>
References: <CAPpHfdvkMdV_nQR3gO41GWJS=2Gjdrm6QhhYH2DwXJ+fMa6gBw@mail.gmail.com>
	<23e82578-b648-ab57-a4af-791abccff344@2ndQuadrant.com>
	<dcff626f-d44d-ad96-ecc0-109601e2cfb9@2ndQuadrant.com>
	<4971.1553779874@sss.pgh.pa.us>
	<5656.1553781027@sss.pgh.pa.us>
	<b2e3d035-4f42-4670-97ad-e79727c40960@2ndQuadrant.com>
	<CAPpHfdu-MvmN9pJnTtTCyuzbcF4t2K4hsfMdEtTGjfx7ZbGVYw@mail.gmail.com>
	<CAPpHfdue-pzzEVK+zoY6sbqG4LYC3JvW7-j8J78EqT-TOLdNiw@mail.gmail.com>
	<19611.1554593792@sss.pgh.pa.us>
	<CAPpHfduP2ShBe3r80u0zsOGxRG1XRd4c7PTj-iPfmv4DzL2dyQ@mail.gmail.com>
	<20190409161557.xwc4xwqeaimxcb4d@development>
	<CAPpHfdvtb3MivKZA-8DUBJux=DwkR2Kx2qoHcw+_TKW7Dwv_Ew@mail.gmail.com>
	<1ccb6aa8-0ba5-a14c-d3a3-8c0b7f73244b@2ndQuadrant.com>
	<CACPNZCt5B8jDCCGQiFoSuqmg-za_NCy4QDioBTLaNRih9+-bXg@mail.gmail.com>

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





view thread (198+ messages)  latest in thread

Message-ID: <14890.1555523005@sss.pgh.pa.us>
Permalink:  ../14890.1555523005@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/14890.1555523005@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, john.naylor@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: jsonpath
  In-Reply-To: <14890.1555523005@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox