Re: [HACKERS] SQL/JSON in PostgreSQL

Поиск
Список
Период
Сортировка
От Oleg Bartunov
Тема Re: [HACKERS] SQL/JSON in PostgreSQL
Дата
Msg-id CAF4Au4zxpFu5o0pHWWMsT2+GHZQ_Jq1i+qS2e1+Lf3rZ+hNKKg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] SQL/JSON in PostgreSQL  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Ответы Re: [HACKERS] SQL/JSON in PostgreSQL
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] SQL/JSON in PostgreSQL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)