Re: [HACKERS] SQL/JSON in PostgreSQL - Mailing list pgsql-hackers

From Oleg Bartunov
Subject Re: [HACKERS] SQL/JSON in PostgreSQL
Date
Msg-id CAF4Au4zxpFu5o0pHWWMsT2+GHZQ_Jq1i+qS2e1+Lf3rZ+hNKKg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] SQL/JSON in PostgreSQL  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: [HACKERS] SQL/JSON in PostgreSQL
List pgsql-hackers


On 10 Jan 2018 20:14, "Andrew Dunstan" <andrew.dunstan@2ndquadrant.com> wrote:


On 01/10/2018 01:37 AM, Oleg Bartunov wrote:
>
>
>
>         this. Something similar to what we're using for json itself (a
>         simple lexer and a recursive descent parser) would be more
>     suitable.
>
>
> flex/bison is right tool for jsonpath, which is complex thing. 



It's not really very complex. The bison grammar has 21 non-terminals. As
languages go that's not huge.

May main concerns are code size and performance. RD parsers are
typically very fast and compact unless they are badly written. There are
reasons that years ago gcc switched from using bison to using a hand cut
RD parser. I guess we wouldn't expect for the most part that jsonpath
expressions would need to be compiled per row, so maybe performance
isn't that critical. But if we do expect really dynamic jsonpath
expressions then we need to make sure we are as fast as we can get.


Good point, our jsonpath can be expression ( the standard describes it as constant literal).


I guess if all you have is a hammer everything looks like a nail, but we
should not assume that bison is the answer to every parsing problem we have.

I'm not going to hold up the patch over this issue. I should probably
have looked closer and raised it months ago. But if and when I get time
I will look into some benchmarking.

I think it's not important right now and we could always replace parser later. 


>     I also note that the later patches have no documentation whatsoever.
>     That needs serious work, and if you want to get these patches in then
>     please supply some documentation ASAP. If you need help with
>     English we
>     can work on that, but just throwing patches of this size and
>     complexity
>     over the wall into the commitfest without any documentation is not the
>     way to proceed.
>
>
> Andrew, we are back from holidays and I will start writing on
> documentation. I have difficulty with design of documentation, since
> it's unclear to me how detailed it should be. I'm inclining to follow
> xml style of documentation, which is quite formal and could be more
> easy to write.


OK, good. The sooner the better though. Err on the side of more detail
please.

cheers

andrew


--

Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] SQL/JSON in PostgreSQL
Next
From: Tom Lane
Date:
Subject: Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)