Re: Tackling JsonPath support

On Mon, Nov 28, 2016 at 6:26 PM, Nico Williams <nico(at)cryptonector(dot)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 <nico(at)cryptonector(dot)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