Re: [HACKERS] SQL/JSON in PostgreSQL
| От | Pavel Stehule |
|---|---|
| Тема | Re: [HACKERS] SQL/JSON in PostgreSQL |
| Дата | |
| Msg-id | CAFj8pRDXH2PiDcoYq7q-AKEogKSR20fzzPXWstXRfaFEX6J_fg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] SQL/JSON in PostgreSQL (Oleg Bartunov <obartunov@gmail.com>) |
| Ответы |
Re: [HACKERS] SQL/JSON in PostgreSQL
|
| Список | pgsql-hackers |
2018-01-06 22:02 GMT+01:00 Oleg Bartunov <obartunov@gmail.com>:
On Sat, Jan 6, 2018 at 8:22 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Hi
>
> I am checking the JSONPath related code
>
> Questions, notes:
>
> 1. jsonpath operators are not consistent with any other .. json, xml .. I am
> missing ?, @> operátors
I have slides about jsonpath
http://www.sai.msu.su/~megera/postgres/talks/sqljson-pgconf. eu-2017.pdf
> 2. documentation issue - there is "'{"a":[1,2,3,4,5]}'::json *? '$.a[*] ? (@
>> 2)'" - operator *? doesn't exists
There are should be @? operator
> 3. operator @~ looks like too aggressive shortcut - should be better
> commented
>
> What is not clean, if jsonpath should to create some new operators for json,
> jsonb types? It is special filter, defined by type, so from my perspective
> the special operators are not necessary.
It's impossible to distinguish jsonpath from text, so introducing new operators
are easier than everytime explicitly specify jsonpath datatype.
There are two possible solutions - special operator or explicit casting. In this case I am not sure if special operator for this case is good solution. Probably nobody will use it - because there SQL/JSON functions, but I don't think so this inconsistency is correct.
I have not strong opinion about it - it will be hidden feature for almost all users.
>
> Regards
>
> Pavel
>
>
В списке pgsql-hackers по дате отправления: