2016-11-29 2:50 GMT+01:00 Christian Convey <christian.con...@gmail.com>:
> On Mon, Nov 28, 2016 at 11:23 AM, Nico Williams <n...@cryptonector.com> > wrote: > ... > >> 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 > >
