Re: [HACKERS] Why is it JSQuery?
On Jun 15, 2014, at 1:58 PM, Josh Berkus j...@agliodbs.com wrote: In other words, what I'm saying is: I don't think there's an existing, poplular syntax we could reasonably use. Okay, I’m good with that. Would be handy to document it in such a way as to kind of put it forward as a standard. :-) D signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [HACKERS] Why is it JSQuery?
On 06/10/2014 02:46 PM, David E. Wheeler wrote: On Jun 10, 2014, at 12:06 PM, Oleg Bartunov obartu...@gmail.com wrote: we have many other tasks than guessing the language name. jsquery is just an extension, which we invent to test our indexing stuff. Eventually, it grew out. I think we'll think on better name if developers agree to have it in core. For now, jsquery is good enough to us. jsquery name doesn't need to be used at all, by the way. Yeah, I was more on about syntax than the name. We can change that any time before you release it. I've been poking at the various json-query syntaxes you forwarded, and none of them really work for the actual jsquery features. Also, the existing syntax has the advantage of being *simple*, relatively speaking, and reasonably similar to JSONPATH. In other words, what I'm saying is: I don't think there's an existing, poplular syntax we could reasonably use. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is it JSQuery?
On 06/15/2014 04:58 PM, Josh Berkus wrote: I've been poking at the various json-query syntaxes you forwarded, and none of them really work for the actual jsquery features. Also, the existing syntax has the advantage of being *simple*, relatively speaking, and reasonably similar to JSONPATH. In other words, what I'm saying is: I don't think there's an existing, poplular syntax we could reasonably use. Not to mention the similarity to tsquery, which is something not to be despised. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is it JSQuery?
On Jun 6, 2014, at 3:50 PM, Josh Berkus j...@agliodbs.com wrote: Maybe we should call it jsonesque ;-) I propose JOQL: JSON Object Query Language. Best, David PS: JAQL sounds better, but [already exists](http://code.google.com/p/jaql/). signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [HACKERS] Why is it JSQuery?
People, we have many other tasks than guessing the language name. jsquery is just an extension, which we invent to test our indexing stuff. Eventually, it grew out. I think we'll think on better name if developers agree to have it in core. For now, jsquery is good enough to us. jsquery name doesn't need to be used at all, by the way. Oleg On Tue, Jun 10, 2014 at 10:04 PM, David E. Wheeler da...@justatheory.com wrote: On Jun 6, 2014, at 3:50 PM, Josh Berkus j...@agliodbs.com wrote: Maybe we should call it jsonesque ;-) I propose JOQL: JSON Object Query Language. Best, David PS: JAQL sounds better, but [already exists](http://code.google.com/p/jaql/). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is it JSQuery?
The closest problem we have is jsonb statistics (lack of, actually) , which prevents use of all the power of jsquery. I hope Jan Urbański could work on this. Oleg On Tue, Jun 10, 2014 at 11:06 PM, Oleg Bartunov obartu...@gmail.com wrote: People, we have many other tasks than guessing the language name. jsquery is just an extension, which we invent to test our indexing stuff. Eventually, it grew out. I think we'll think on better name if developers agree to have it in core. For now, jsquery is good enough to us. jsquery name doesn't need to be used at all, by the way. Oleg On Tue, Jun 10, 2014 at 10:04 PM, David E. Wheeler da...@justatheory.com wrote: On Jun 6, 2014, at 3:50 PM, Josh Berkus j...@agliodbs.com wrote: Maybe we should call it jsonesque ;-) I propose JOQL: JSON Object Query Language. Best, David PS: JAQL sounds better, but [already exists](http://code.google.com/p/jaql/). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is it JSQuery?
On Jun 10, 2014, at 12:06 PM, Oleg Bartunov obartu...@gmail.com wrote: we have many other tasks than guessing the language name. jsquery is just an extension, which we invent to test our indexing stuff. Eventually, it grew out. I think we'll think on better name if developers agree to have it in core. For now, jsquery is good enough to us. jsquery name doesn't need to be used at all, by the way. Yeah, I was more on about syntax than the name. We can change that any time before you release it. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [HACKERS] Why is it JSQuery?
Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts. On Fri, Jun 6, 2014 at 4:34 AM, David E. Wheeler da...@justatheory.com wrote: On Jun 5, 2014, at 5:25 PM, Andrew Dunstan and...@dunslane.net wrote: My understanding is that it's meant to be analogous to tsquery. At first glance, JsonPath doesn't seem to support AND and OR operators, which would make it rather less expressive than I gather JSQuery is meant to be. Yes, but perhaps it could be a superset. I guess my real question is: Should it not be based on some existing dialect, preferably something in fairly wide use outside the Postgres community? Unless that something is awful, of course. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is it JSQuery?
On Jun 6, 2014, at 6:54 AM, Oleg Bartunov obartu...@gmail.com wrote: Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts. Sure, but could we not potentially build on its syntax, instead of building a new one? I’m not saying we *should*, but if we don’t, I think there should be a discussion about why not. For example, I think it would not be a good idea to follow [JSONiq](http://www.jsoniq.org/) because who wants to write queries in JSON? (Have we learned nothing from XSLT?). Here’s a (partial) list of existing JSON query languages: http://stackoverflow.com/a/7812073/79202 The arguments might be: * [JSONiq](http://jsoniq.org/): Queries in JSON? Gross! * [UNQL](http://www.unqlspec.org/): Too similar to SQL * [JAQL](https://code.google.com/p/jaql/): Too different from SQL * [JSONPath](http://goessner.net/articles/JsonPath/): Too verbose * [JSON Query](https://github.com/mmckegg/json-query): Too little there * [Mongo](http://www.mongodb.org/display/DOCS/Inserting#Inserting-JSON): Gross syntax * [LINQ](http://james.newtonking.com/archive/2008/03/02/json-net-2-0-beta-2): Too similar to SQL * [searchjs](https://github.com/deitch/searchjs): Queries in JSON? Gross! * [JQuery](http://jquery.org/): It's for HTML, not JSON * [SpahQL](http://danski.github.io/spahql/): More like XPath * [ObjectPath](http://adriank.github.io/ObjectPath/): Too verbose * [JFunk](https://code.google.com/p/jfunk/): XPathy * [JData](http://jaydata.org): Queries in JavaScript? C’mon. These are just off-the-cuff evaluations in 10 minutes of looking -- surely not all of them are accurate. Some of them maybe *are* useful to emulate. It’s definitely worthwhile, IMHO, to evaluate prior art and decide what, if any of it, should inspire the JSQuery syntax, and there should be reasons why and why not. I do think that the name should be changed if we don’t follow an existing standard, as [JSQuery](https://code.google.com/p/gwtquery/wiki/JsQuery) is already a thing. Best, David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [HACKERS] Why is it JSQuery?
On 06/06/2014 09:12 AM, David E. Wheeler wrote: On Jun 6, 2014, at 6:54 AM, Oleg Bartunov obartu...@gmail.com wrote: Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts. Sure, but could we not potentially build on its syntax, instead of building a new one? I’m not saying we *should*, but if we don’t, I think there should be a discussion about why not. For example, I think it would not be a good idea to follow [JSONiq](http://www.jsoniq.org/) because who wants to write queries in JSON? (Have we learned nothing from XSLT?). Here’s a (partial) list of existing JSON query languages: http://stackoverflow.com/a/7812073/79202 The arguments might be: * [JSONiq](http://jsoniq.org/): Queries in JSON? Gross! Also overly complex for the functionality we support. There's also no way to make the jsquery strings valid JSON without adding a bunch of extra text. * [UNQL](http://www.unqlspec.org/): Too similar to SQL ... also intended to be a *complete* replacement for SQL, whereas we just want a syntax to search JSON fields. * [JAQL](https://code.google.com/p/jaql/): Too different from SQL * [JSONPath](http://goessner.net/articles/JsonPath/): Too verbose I don't agree with the too verbose, but lacking AND|OR is pretty crippling. * [JSON Query](https://github.com/mmckegg/json-query): Too little there * [Mongo](http://www.mongodb.org/display/DOCS/Inserting#Inserting-JSON): Gross syntax * [LINQ](http://james.newtonking.com/archive/2008/03/02/json-net-2-0-beta-2): Too similar to SQL * [searchjs](https://github.com/deitch/searchjs): Queries in JSON? Gross! * [JQuery](http://jquery.org/): It's for HTML, not JSON * [SpahQL](http://danski.github.io/spahql/): More like XPath * [ObjectPath](http://adriank.github.io/ObjectPath/): Too verbose * [JFunk](https://code.google.com/p/jfunk/): XPathy * [JData](http://jaydata.org): Queries in JavaScript? C’mon. These are just off-the-cuff evaluations in 10 minutes of looking -- surely not all of them are accurate. Some of them maybe *are* useful to emulate. It’s definitely worthwhile, IMHO, to evaluate prior art and decide what, if any of it, should inspire the JSQuery syntax, and there should be reasons why and why not. Well, I'd also say that we don't care about syntaxes which are not already popular. There's no point in being compatible with something nobody uses. How many of the above have any uptake? Also, the explosion of query languages in this area is not an encouraging sign for us being able to pick the right one. UUID-OSSP anyone? So the advantage of the current jsquery syntax is that it's similar to tsquery, which already has some adoption in our userbase. On the other hand, I'm not sure how many people actually understand the tsquery syntax, and jsquery will be different enough to trip people up. I do think that the name should be changed if we don’t follow an existing standard, as [JSQuery](https://code.google.com/p/gwtquery/wiki/JsQuery) is already a thing. I saw that too, but I don't get the impression that Google jsquery is all that active. No? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is it JSQuery?
On Jun 6, 2014, at 12:51 PM, Josh Berkus j...@agliodbs.com wrote: * [JAQL](https://code.google.com/p/jaql/): Too different from SQL * [JSONPath](http://goessner.net/articles/JsonPath/): Too verbose I don't agree with the too verbose, but lacking AND|OR is pretty crippling. I had enough people complain about Test::XPath, which tests the structure of XML and HTML documents using XPath. They didn't like how verbose XPath was, preferring CSS selectors. So I ended up with a patch to support CSS syntax, too. CSS-style syntax is part of what people like about JQuery, too. Well, I'd also say that we don't care about syntaxes which are not already popular. There's no point in being compatible with something nobody uses. How many of the above have any uptake? I think there is JQuery, JSONPath, and everything else, really. If we can draw some parallels, I think that would be sufficient to make people comfortable. I do think that the name should be changed if we don’t follow an existing standard, as [JSQuery](https://code.google.com/p/gwtquery/wiki/JsQuery) is already a thing. I saw that too, but I don't get the impression that Google jsquery is all that active. No? It’s Google. You really want to wrangle with their attorneys? David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [HACKERS] Why is it JSQuery?
On 06/06/2014 03:23 PM, David E. Wheeler wrote: On Jun 6, 2014, at 12:51 PM, Josh Berkus j...@agliodbs.com wrote: Well, I'd also say that we don't care about syntaxes which are not already popular. There's no point in being compatible with something nobody uses. How many of the above have any uptake? I think there is JQuery, JSONPath, and everything else, really. If we can draw some parallels, I think that would be sufficient to make people comfortable. Well, then those are the only ones worth considering. I do think that the name should be changed if we don’t follow an existing standard, as [JSQuery](https://code.google.com/p/gwtquery/wiki/JsQuery) is already a thing. I saw that too, but I don't get the impression that Google jsquery is all that active. No? It’s Google. You really want to wrangle with their attorneys? Google is not going to sue us over a minor OSS project which isn't a commercial product. The relevant question is: are users liable to confuse our jsquery with Google jsquery? Maybe we should call it jsonesque ;-) -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is it JSQuery?
On 06/05/2014 08:08 PM, David E. Wheeler wrote: Oleg, Teodor, and Hackers: Love what you’re doing with JSQuery. I’m curious, though, whether you considered adopting an existing syntax, such as JSONPath. http://goessner.net/articles/JsonPath/ Might be easier for people to pick up and use. Thoughts? My understanding is that it's meant to be analogous to tsquery. At first glance, JsonPath doesn't seem to support AND and OR operators, which would make it rather less expressive than I gather JSQuery is meant to be. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is it JSQuery?
On Jun 5, 2014, at 5:25 PM, Andrew Dunstan and...@dunslane.net wrote: My understanding is that it's meant to be analogous to tsquery. At first glance, JsonPath doesn't seem to support AND and OR operators, which would make it rather less expressive than I gather JSQuery is meant to be. Yes, but perhaps it could be a superset. I guess my real question is: Should it not be based on some existing dialect, preferably something in fairly wide use outside the Postgres community? Unless that something is awful, of course. David signature.asc Description: Message signed with OpenPGP using GPGMail
