This submission is for PostgreSQL's "JSON Path", which is very similar to the original JSONPath. I'm surprised, and disappointed, that there is no mention of the original JSONPath, which this is obviously inspired by.
Well, they say that they did not invent it, they have just implemented it as defined in ISO/IEC 9075:2016 standard [0]
It is entirely possible that ISO design is based of Goessner’s work, but unfortunately it is just history at this point. Unfortunately this is what standardization often does - the work becomes attributed to organization, and individual authors are forgotten.
So, what I'm seeing is that I currently have JQ, and if I get around to dealing with Postgre, I might also have SQL's JSONPath. And then if I get tired of juggling objects/dicts/arrays in my programs, I can also pick a not-quite-the-same JSONPath as a lib.
(Though the latter is unlikely, since Lisp and FP have taught me that a bunch of functions feeding into each other will do exactly the same thing quite fine.)
Also of interest is RFC 6901, JSON Pointer, https://tools.ietf.org/html/rfc6901. That spec is much simpler (and syntactically incompatible, I may add), providing unique paths to elements inside a JSON document, and not handling any sorts of queries, as these Jsonpath and JSONPath things both do.
JSON Pointer is not ubiquitous by any means, but it does got use in diverse APIs. Most recently, JMAP uses it for backreferences.
(The naming of these things is a mess. XPath deals in what you could call queries or selectors, not what I would be willing to call paths; JSONPath adopted XPath’s bad name presumably for marketing reasons, and so what became RFC 6901 presumably went with the name JSON Pointer instead of the obvious name of JSON Path to avoid confusion, as it was coming well after JSONPath.)
Is there a detailed comparison between JSONpath and jq? I'm esp interested in examples where jq is more powerful, e.g. jq one liner but JSONpath can't.
Does anybody else feel that the syntax is terrible and SQL is not a good fit for this? I, for one, would appreciate if the paths were accessible via a change to the SQL syntax as opposed to a magic operator or - even worse - a new function. Not to mention that the more complex the queries become, the more pain one can expect the query planner to be... personally, I'd prefer to make my own query plans instead, laying down the algorithms according to the best of my knowledge of the dataset.
It's not like optimizing in C, where the compiler looks at the AST and can actually discover something you wouldn't think of. My experience with PostgreSQL's query planner is that it requires so much fine-tuning it's near unusable and super quirky.
That isn't to say that I don't like PostgreSQL and its JSON capabilities - it's just that the more I use it, the more I wish there was something between it and current NoSQL databases...
> Interesting to see the old Soviet Union TLD is still in use.
Weird to see a proper institution on that domain. The .su itself is quite alive and available for registration. It's mostly used as a “quirky knockoff tld,” in the spirit of .io and such.
Mostly inspired by jsonpath -- IIRC I implemented as much of it which made sense like dotted tree lookup "tree.foo.bar", lambda searching (which I was tempted to name "where"(e.g. "for key, value in tree.foo.bar.where(lambda k,v: k > 100)") but thought better of it), equality and comparison operators and a few other things I can't quite remember off the top of my head.
Doesn't do expression parsing (edit: actually...it does a limited form of expression parsing inherited from the C++ lib) but works for the couple simple projects I needed it for.
[+] [-] cle|6 years ago|reply
https://goessner.net/articles/JsonPath/
This submission is for PostgreSQL's "JSON Path", which is very similar to the original JSONPath. I'm surprised, and disappointed, that there is no mention of the original JSONPath, which this is obviously inspired by.
[+] [-] theamk|6 years ago|reply
It is entirely possible that ISO design is based of Goessner’s work, but unfortunately it is just history at this point. Unfortunately this is what standardization often does - the work becomes attributed to organization, and individual authors are forgotten.
[0] https://modern-sql.com/blog/2017-06/whats-new-in-sql-2016
[+] [-] aasasd|6 years ago|reply
(Though the latter is unlikely, since Lisp and FP have taught me that a bunch of functions feeding into each other will do exactly the same thing quite fine.)
[+] [-] chrismorgan|6 years ago|reply
JSON Pointer is not ubiquitous by any means, but it does got use in diverse APIs. Most recently, JMAP uses it for backreferences.
(The naming of these things is a mess. XPath deals in what you could call queries or selectors, not what I would be willing to call paths; JSONPath adopted XPath’s bad name presumably for marketing reasons, and so what became RFC 6901 presumably went with the name JSON Pointer instead of the obvious name of JSON Path to avoid confusion, as it was coming well after JSONPath.)
[+] [-] dang|6 years ago|reply
[+] [-] donpdonp|6 years ago|reply
https://stedolan.github.io/jq/manual/
[+] [-] asah|6 years ago|reply
[+] [-] d33|6 years ago|reply
It's not like optimizing in C, where the compiler looks at the AST and can actually discover something you wouldn't think of. My experience with PostgreSQL's query planner is that it requires so much fine-tuning it's near unusable and super quirky.
That isn't to say that I don't like PostgreSQL and its JSON capabilities - it's just that the more I use it, the more I wish there was something between it and current NoSQL databases...
[+] [-] hyuuu|6 years ago|reply
[+] [-] picod|6 years ago|reply
you can try it here http://json.jasaws.com/
[+] [-] Kip9000|6 years ago|reply
[+] [-] klodolph|6 years ago|reply
[+] [-] stonogo|6 years ago|reply
There's a pretty nice jsonpath implementation that was recently produced at https://github.com/pacifica/python-jsonpath2
I haven't switched to it yet, but I'm keeping an eye on it, to see how long it's supported
[+] [-] aasasd|6 years ago|reply
Weird to see a proper institution on that domain. The .su itself is quite alive and available for registration. It's mostly used as a “quirky knockoff tld,” in the spirit of .io and such.
[+] [-] UncleEntity|6 years ago|reply
Mostly inspired by jsonpath -- IIRC I implemented as much of it which made sense like dotted tree lookup "tree.foo.bar", lambda searching (which I was tempted to name "where"(e.g. "for key, value in tree.foo.bar.where(lambda k,v: k > 100)") but thought better of it), equality and comparison operators and a few other things I can't quite remember off the top of my head.
Doesn't do expression parsing (edit: actually...it does a limited form of expression parsing inherited from the C++ lib) but works for the couple simple projects I needed it for.
[+] [-] Emily1636|6 years ago|reply
[deleted]