Re: Tackling JsonPath support
От | Pavel Stehule |
---|---|
Тема | Re: Tackling JsonPath support |
Дата | |
Msg-id | CAFj8pRAYcPFfiX=R=GnFop9Czbu1ArR3CczH-v0JZG8v-xUG_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Tackling JsonPath support (Christian Convey <christian.convey@gmail.com>) |
Ответы |
Re: Tackling JsonPath support
Re: Tackling JsonPath support |
Список | pgsql-hackers |
2016-11-27 17:50 GMT+01:00 Christian Convey <christian.convey@gmail.com>:
From looking at other databases' docs, it seems like the behavior of various JSON-related operators / functions are described partially in terms of a "json path expression":* In Oracle, "JSON_TABLE", "JSON_exists_column", "JSON_value_column": [1]* In MySQL: [2]* In DB2: [3]* In MS SQL Server: [4]* (Whatever the Standards committee will end up producing.)If I'm correctly understanding the situation, It sounds like we have two big unknowns:(a) The exact syntax/semantics of JSON path searching, especially w.r.t. corner cases and error handling, and(b) The syntax/semantics of whatever SQL operators / functions are currently defined in terms of (a). E.g., "JSON_TABLE".If that's correct, then what do you guys think about us taking the following incremental approach?Step 1: I'll dig into the implementations described above, to see what's similar and different between the JSON-path-expression syntax and semantics offered by each. I then report my findings here, and we can hopefully reach a consensus about the syntax/semantics of PG's json-path-expression handling.Step 2: I submit a patch for adding a new function to "contrib", which implements the JSON-path-expression semantics chosen in Step 1. The function will be named such that people won't confuse it with any (eventual) SQL-standard equivalent.Step 3: PG developers can, if they choose, start defining new JSON operator / functions, and/or port existing JSON-related functions, in terms of the function created in Step 2.I see the following pros / cons to this approach:Pro: It gives us a concrete start on this functionality, even though we're not sure what's happening with the SQL standard.Pro: The risk of painting ourselves into a corner is relatively low, because we're putting the functionality in "contrib", and avoid function names which conflict with likely upcoming standards.Pro: It might permit us to give PG users access to JSONPath -like functionality sooner than if we wait until we're clear on the ideal long-term interface.
Incremental work is great idea - I like this this style. Instead contrib, you can use public repository on github. Minimally for first stage is better to live outside core - you are not restricted by PostgreSQL development process. When your code will be stabilized, then you can go to commitfest. I believe so we need good JSON support. The XML support helps to PostgreSQL lot of, JSON will be great too.
Con: "JSON path expression" is a recurring them in the *grammars* of user-facing operators in [1], [2], [3], and [4]. But it doesn't necessarily follow that the function implemented in Step 2 will provide useful infrastructure for PG's eventual implementations of "JSON_TABLE", etc.
We can implement subset only - our XPath based on libxml2 does it too. The good target is support of usual examples on the net.
Regards
Pavel
В списке pgsql-hackers по дате отправления: