From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | obartunov(at)gmail(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:14:34 |
Message-ID: | e5749d3e-6f10-6112-28b1-bd093d198771@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2018-01-10 17:22:26 | Re: [HACKERS] SQL/JSON in PostgreSQL |
Previous Message | Alvaro Herrera | 2018-01-10 17:02:04 | Re: CUBE seems a bit confused about ORDER BY |