On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams <n...@cryptonector.com>

> 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

Reply via email to