On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams <n...@cryptonector.com> wrote:
> On Mon, Nov 28, 2016 at 05:50:40PM -0800, Christian Convey wrote: > > 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"? > > jq is a functional language that has these and other features: > > - recursion > - generators > - lazy evaluation (of sorts) > - path expressions > - math functionality (libm, basically) > - reduction > - functions > - and other things > > (jq does not have higher-order functions in that functions cannot return > functions and functions are not values, though it does have closures.) > > jq is and feels a lot like a SQL, but for JSON. > > > 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. > > SQL imposes structure on data. Recursion makes SQL structure looser in > the sense that it may not be easy or possible to express certain > desirable schema constraints in SQL terms without resorting to triggers, > say. Storing documents in XML, JSON, or other such recursion-friendly > formats (perhaps in semantically equivalent but query-optimized forms) > is also a way to avoid strict structure (thus one needs schema > validators for XML, for example). > > Less rigid schema constraints do not and should not preclude powerful > query languages. > > One could convert such documents to a SQL EAV schema, if one has an > RDBMS with an ANY type (e.g., something like SQLite3's duck typing), and > then use SQL to query them. But that may be more difficult to use than > a SQL with support for XML/JSON/... and query sub-languages for those. > > SQL is very powerful. One might like to have similarly powerful, > format-specific query languages for documents stored in XML, JSON, > etcetera, in a SQL RDBMS. jq is such a language, for JSON documents. > Ditto XPath/XSLT, for XML. While XPath is expressive and compact, XSLT > is rather verbose; jq is as expressive as XSLT, but with the compact > verbosity of XPath. > > > Since I myself have no need currently for this functionality, I'm left > > guessing about hypothetical users of it. My current mental model is: > > That's a bit like asking what is the use for SQL :^) The point is that > SQL is a powerful query language, and so is jq. Each is appropriate to > its own domain; both could be used together. > Thanks for the explanation. It sounds like your original point was NOT that json-path isn't sufficient for "${specific use X}". Instead, your point was that jq seems to have many advantages over json-path in general, and therefore PG should offer jq instead or, or in addition to, json-path. Is that what you're saying? ... > > (c) Pavel. (I'm still somewhat unclear on what has him interested in > this, > > and what his specific constraints are.) > > Hmm? > Context: The reason I'm trying to work on a json-path implementation is that Pavel Stehule suggested it as a good first PG-hacking project for me. At the time, it sounded like he had a use for the feature. - C