Re: [HACKERS] SQL/JSON in PostgreSQL
От | Nikita Glukhov |
---|---|
Тема | Re: [HACKERS] SQL/JSON in PostgreSQL |
Дата | |
Msg-id | 2361ae4a-66b1-c6c5-ea6a-84851a1c08b5@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] SQL/JSON in PostgreSQL (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [HACKERS] SQL/JSON in PostgreSQL
Re: [HACKERS] SQL/JSON in PostgreSQL |
Список | pgsql-hackers |
On 29.09.2017 20:07, Pavel Stehule wrote:
Yes, it can be easily separated. Attached archive with separated GIN patch no.2.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>:Yes, this is still the latest version. Now I am working only on unfinished WIPI have some free time now. Is it last version?RegardsPavel
patch no. 9, but I think it should be reviewed the last.okThank youI have few queries and notes1. Why first patch holds Gin related functionality? Can be it separated?
Originally, these functions were created only for testing purposes and should2. Why Json path functions starts by "_" ? These functions are not removed by other patches.
be treated as "internal". But with introduction of jsonpath operators jsonpath
tests can be completely rewritten using this operators.
Our jsonpath extensions are not based on any standards, so they are quite3. What is base for jsonpath-extensions? ANSI/SQL?
dangerous because they can conflict with the standard in the future.
I think it's acceptable. And this was the main reason for the separation of patches.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 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.
Вложения
В списке pgsql-hackers по дате отправления: