Re: SQL/JSON in PostgreSQL
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: Oleg Bartunov <obartunov@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Daniel Gustafsson <daniel@yesql.se>,
Alexander Korotkov <a.korotkov@postgrespro.ru>, Teodor Sigaev <teodor@postgrespro.ru>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, David Steele <david@pgmasters.net>, Andres Freund <andres@anarazel.de>, Pgsql Hackers <pgsql-hackers@postgresql.org>,
andrew Dunstan <andrew@dunslane.net>
Date: 2017-09-30T04:28:52Z
Lists: pgsql-hackers
2017-09-30 1:06 GMT+02:00 Nikita Glukhov <n.gluhov@postgrespro.ru>: > On 29.09.2017 20:07, Pavel Stehule wrote: > > 2017-09-29 12:15 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>: > >> >> 2017-09-29 12:09 GMT+02:00 Nikita Glukhov <n.gluhov@postgrespro.ru>: >> >>> >>> >>> I have some free time now. Is it last version? >>> >>> Regards >>> >>> Pavel >>> >>> Yes, this is still the latest version. Now I am working only on >>> unfinished WIP >>> patch no. 9, but I think it should be reviewed the last. >>> >>> >> >> ok >> >> Thank you >> > > I have few queries and notes > > 1. Why first patch holds Gin related functionality? Can be it separated? > > Yes, it can be easily separated. Attached archive with separated GIN patch > no.2. > > 2. Why Json path functions starts by "_" ? These functions are not removed > by other patches. > > Originally, these functions were created only for testing purposes and > should > be treated as "internal". But with introduction of jsonpath operators > jsonpath > tests can be completely rewritten using this operators. > > 3. What is base for jsonpath-extensions? ANSI/SQL? > > Our jsonpath extensions are not based on any standards, so they are quite > dangerous because they can conflict with the standard in the future. > > This patch is pretty big - so I propose to push JSONPath and SQL/JSON > related patches first, and then in next iteration to push JSON_TABLE patch. > Is it acceptable strategy? > > I think it's acceptable. And this was the main reason for the separation > of patches. > I prefer to move it to another commit fest item. It will simplify a communication between us and possible committers - and we can better concentrate to smaller set of code. > I am sure so JSON_TABLE is pretty important function, but it is pretty > complex too (significantly more complex than XMLTABLE), so it can be > practiacal to move this function to separate project. I hope so all patches > will be merged in release 11 time. > > > -- > Nikita Glukhov > Postgres Professional: http://www.postgrespro.com > The Russian Postgres Company >
Commits
-
SQL/JSON: support the IS JSON predicate
- 6ee30209a6f1 16.0 landed
-
SQL/JSON: add standard JSON constructor functions
- 7081ac46ace8 16.0 landed