Re: Tackling JsonPath support
От | Pavel Stehule |
---|---|
Тема | Re: Tackling JsonPath support |
Дата | |
Msg-id | CAFj8pRAtvZAtA2OBiyZyjf+AC24g6oSuKsbA8uWGZFZOoq=hDw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Tackling JsonPath support (Christian Convey <christian.convey@gmail.com>) |
Ответы |
Re: Tackling JsonPath support
|
Список | pgsql-hackers |
2016-11-29 2:50 GMT+01:00 Christian Convey <christian.convey@gmail.com>:
...JSON Path is not expressive enough (last I looked) and can be mapped
onto jq if need be anyways.Hi Nico,Could you please clarify what you mean by "not expressive enough"?I ask because I've been struggling to identify clear requirements for the json-path functionality I'm trying to provide. It sounds like perhaps you have something concrete in mind.Since I myself have no need currently for this functionality, I'm left guessing about hypothetical users of it. My current mental model is:(a) Backend web developers. AFAICT, their community has mostly settled on the syntax/semantics proposed by Stefan Groessner. It would probably be unkind for PG's implementation to deviate from that without a good reason.(b) PG hackers who will eventually implement the ISO SQL standard operators. In the standards-committee meeting notes I've seen, it seemed to me that they were planning to define some operators in terms of json-path expression. So it would probably be good if whatever json-path function I implement turns out to comply with that standard, so that the PG-hackers can use it as a building block for their work.(c) Pavel. (I'm still somewhat unclear on what has him interested in this, and what his specific constraints are.)
My target is simple - 1. to have good ANSI/SQL support, 2. to have good JSON to relation mapping function - ANSI/SQL JSONTABLE does it.
We now support XPath function - JSONPath is similar to XPath - it is better for user, because have to learn only one language.
Regards
Pavel
- Christian
В списке pgsql-hackers по дате отправления: