Re: Tackling JsonPath support
| От | Christian Convey |
|---|---|
| Тема | Re: Tackling JsonPath support |
| Дата | |
| Msg-id | CAPfS4Zyjh4F9OWTsc4EJKh=1NR_qU+7GLZr0BC4bq9KULEf75Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Tackling JsonPath support (Petr Jelinek <petr@2ndquadrant.com>) |
| Ответы |
Re: Tackling JsonPath support
|
| Список | pgsql-hackers |
...
Just to add to this, the SQL/JSON proposals I've seen so far, and what
Oracle, MSSQL and Teradata chose to implement already is basically
subset of jsonpath (some proposals/implementations also include
lax/strict prefix keyword on top of that). I think that should give us
some hint on what the base functionality should look like.
I agree. My guess is that PG users would benefit most from:
(1) Conformance to whatever ISO standard regarding JSON operators eventually makes it out of the working group.
(2) Compatibility with other widely-used DBMS's.
(3) Compatibility with the JSONPath functionality used by web developers. (Although I don't currently have a grasp on which frameworks / libraries this entails.)
I *think* that (1), (2), and (3) are in approximate agreement about the syntax and semantics of the path-expression language: the language proposed by Stefan Groessner, plus the strict vs. lax distinction.
I think I can satisfy (3) with a PG extension which provides a function that approximately implements JSONPath. My short-term plans are to submit such a patch.
Hopefully that patch's function will be a helpful starting point for satisfying (1) and (2) as well. But that can be decided later.
Nico Williams has argued for using "jq". I don't think jq satisfies any of (1), (2), or (3), so I don't see a good case for incorporating it in my short-term plans. There *may* be a case for using jq internally to my implementation; I'll try to look into that.
В списке pgsql-hackers по дате отправления: