Skip site navigation (1) Skip section navigation (2)


From: Oleg Bartunov <obartunov(at)gmail(dot)com>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Pavel Stěhule <pavel(dot)stehule(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Piotr Stefaniak <email(at)piotr-stefaniak(dot)me>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)postgrespro(dot)ru>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: [HACKERS] SQL/JSON in PostgreSQL
Date: 2018-01-10 17:22:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 10 Jan 2018 20:14, "Andrew Dunstan" <andrew(dot)dunstan(at)2ndquadrant(dot)com>

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

>     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




Andrew Dunstan      
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2018-01-10 17:22:34
Subject: Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)
Previous:From: Andrew DunstanDate: 2018-01-10 17:14:34
Subject: Re: [HACKERS] SQL/JSON in PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group