Came across this a few time but never got to try it out because the only golang binding is unofficial and I can't get CGO to work as expected... That would be really neat to have an official one. This articles makes me want to try it even more
Friendlier SQL with DuckDB
31–40 of 134 posts
Re: Friendlier SQL with DuckDB
#32I find that the examples are very confusing because they are using names that sound like rows or tables (jar_jar_binks, planets) as fields in the examples.
Ah, well, that was a risk that I took... Thank you for the feedback though! The Star Wars puns were too hard to resist... If you have a specific question, definitely post it here and I will clarify!
Keep the puns, I just think with a bit of adjustment the examples would be easier to understand.
Re: Friendlier SQL with DuckDB
#33`EXCLUDE` Extremely useful, is there a reason why this is something not implemented in SQL in the first place? I often find myself writing very long queries just to select basically all columns except for two or three of them.
Re: Friendlier SQL with DuckDB
#34Came across this a few time but never got to try it out because the only golang binding is unofficial and I can't get CGO to work as expected... That would be really neat to have an official one. This articles makes me want to try it even more
Here is a solved Github Issue related to CGO for the Go bindings! If you have another issue, please feel free to post it on their Github page! https://github.com/marcboeker/go-duckdb/issues/4
Re: Friendlier SQL with DuckDB
#35`EXCLUDE` Extremely useful, is there a reason why this is something not implemented in SQL in the first place? I often find myself writing very long queries just to select basically all columns except for two or three of them.
because columns can be added to tables in production databases, so any time you use select * you run the chance the number of columns changing and breaking anything you wrote.
Re: Friendlier SQL with DuckDB
#36Lots of great additions. I will just highlight two: Column selection : When you have tons of columns these become useful. Clickhouse takes it to the next level and supports APPLY and COLUMN in addition to EXCEPT, REPLACE which DuckDB supports: - APPLY: apply a function to a set of columns - COLUMN: select columns by matching a regular expression (!) Details here: https://clickhouse.com/docs/en/sql-reference/statement…
> Allowing for trailing commas should get included in the SQL spec. Yep! That would be my #1 request for SQL. Seems ridiculous that it's not supported already.
Re: Friendlier SQL with DuckDB
#37That 750KB PNG can probably be a 50KB PNG. Even without resizing it compresses to less than half its size. https://duckdb.org/images/blog/duck_chewbacca.png
Thanks! Can you tell that my SQL-fu is stronger than my HTML-fu? :-) Much appreciated!
Re: Friendlier SQL with DuckDB
#38`EXCLUDE` Extremely useful, is there a reason why this is something not implemented in SQL in the first place? I often find myself writing very long queries just to select basically all columns except for two or three of them.
because columns can be added to tables in production databases, so any time you use select * you run the chance the number of columns changing and breaking anything you wrote.
Re: Friendlier SQL with DuckDB
#39Re: Friendlier SQL with DuckDB
#40How does DuckDB compare to SQLite (e.g. which workloads are a good fit for what? Would it be a good idea to use both?) I found https://duckdb.org/why_duckdb but I'm sure someone here can share some real world lessons learned?
Excellent question! I'll jump in - I am a part of the DuckDB team though, so if other users have thoughts it would be great to get other perspectives as well. First things first - we really like quite a lot about the SQLite approach. DuckDB is similarly easy to install and is built without dependencies, just like SQLite. It also runs in the same process as your application just like SQLite does. SQLite is excellent a…