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. > (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. I can't speak for the community. I wouldn't take it personally that jq be not chosen, nor any other proposal of mine. If it's politically easier, then do that. > (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. These could still be implemented (e.g., using jq itself). > (c) Pavel. (I'm still somewhat unclear on what has him interested in this, > and what his specific constraints are.) Hmm? Nico -- -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers