Re: [HACKERS] SQL/JSON in PostgreSQL

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

In response to

Responses

Browse pgsql-hackers by date

  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