-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: reference fields within jsonb/json entries in postgres #143
Comments
@c-nv-s Interesting idea. Do you have a concept in your mind of what the syntax for that might look like? |
whatever keeps it most transparent for the end user that you can think of.
in sq this could look something like this:
|
but if you think that could get very verbose with all the selectors, you could go fully declarative like this guy haha https://github.com/xcite-db/Unquery/blob/main/TUTORIAL.adoc |
I'd never seen that tool before. There are dozens of us! |
Thanks for the input @c-nv-s . The latter suggestion with the double colons ( $ sq '.actor | .first_name:given_name' The postgres "pointer style" might work, e.g. $ sq '.actor.jsonblob->age'. That would combine with column aliases to look like: $ sq '.actor.jsonblob->age:how_old' That doesn't seem too bad. Now, to combine it with whitespace names: $ sq '.actor."json blob"->"person age":how_old' Again, that could work. For further nested JSON: $ sq '.actor.jsonblob->person.age' That seems pretty ok. I'll have to give it some more noodling. Let me know if you have additional thoughts. |
Or maybeeee something like: $ sq .actor.jsonblob[person.age] Although I'm not sure I like that as much. |
One potential downside to the arrow is that I was considering using it to incorporate insertion into the query language. Right now you can do: $ sq .actor --insert @othersrc.table The theory being that MAYBE the insert could be implemented as: $ sq '.actor -> @othersrc.table' But I'm pretty lukewarm about it. There's other options too, like $ sq '.actor | insert(@othersrc.table)' Which might be clearer. Again, not sure if we'll take this route at all, or if the query language should stay exclusively for querying. |
Another thing that drew me to sq was the prospect of having a tool that work similarly to jq which eases the brain tax of having to learn multiple languages and thier individual quirks. fyi (just in case it wasn't clear) I mentioned this because I would say that your last example of the possible |
any more thoughts on this request? this feature and inline datasources are the final puzzle piece for me with this tool. |
@c-nv-s I'm finally investigating JSON support (can you tell I have thanksgiving week off? 😉)... Quick question for you: do you use the "native" pg JSON operators in your queries, or jsonpath queries? E.g. I've got a test table with info about GitHub repos (just because their API is a good source of JSON), looking like this: $ sq inspect .github_json_awk5z6e6 -v
NAME TYPE ROWS COLS NAME TYPE PK
github_json_awk5z6e6 table 2 3 repo_name text
repo json
issues json Do you do this? select gh.repo::json->>'node_id'
from github_json_awk5z6e6 gh; Or this? select jsonb_path_query(gh.repo::jsonb, '$.node_id')->>0
from github_json_awk5z6e6 gh; At this point, I'm leaning towards implementing the feature syntax via jsonpath, largely because that seems more portable across different databases, e.g. MySQL, SQL Server, etc. So, right now, the $ sq '.github_json_awk5z6e6 | .repo->>$.node_id' But, I'm still in the investigation phase. What would be really helpful is if you could provide some sample queries that you use in your workflow 🙏. I need a feel for how complex they might be. And any other early feedback is very welcome too. |
Although, being that jsonpath is effectively another language to learn, maybe I'll wrap a jq veneer over the jsonpath. E.g. given this: select jsonb_path_query(issues::jsonb, '$[*].title')->>0
from github_json_awk5z6e6; In jsonpath style, that would be: $ sq '.github_json_awk5z6e6 | .issues->$[*].title' But, in jq style, it would be: $ sq '.github_json_awk5z6e6 | .issues->.[].title' |
hey neil, that jq style veneer does look nice and intuitive. To answer your first question, I use the first mentioned query style, however my intention is to to get json responses as quickly as I can out of postgres and into jq, so my queries to postgres would usually aim for the most sensible top level node of the json and then the rest of the data manipulation would be done with jq.
I'll see if I can paste a snippet from the little postgres json cheatsheet I collated from various online sources |
some snippets from my cheatsheet sourced online (was never intended for public viewing but what the hell)
|
would be nice if sq could reference fields from json data that has been saved in a table under the
jsonb
orjson
type in postgres.The text was updated successfully, but these errors were encountered: