Re: Tackling JsonPath support

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.

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.

- Christian