2017-09-30 1:06 GMT+02:00 Nikita Glukhov <n.glu...@postgrespro.ru>: > On 29.09.2017 20:07, Pavel Stehule wrote: > > 2017-09-29 12:15 GMT+02:00 Pavel Stehule <pavel.steh...@gmail.com>: > >> >> 2017-09-29 12:09 GMT+02:00 Nikita Glukhov <n.glu...@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 >
