Live data from Hacker News

Friendlier SQL with DuckDB

duckdb.org

31–40 of 134 posts

Re: Friendlier SQL with DuckDB

#31
post #29

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

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

#32

I 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!

I'd agree. Took me a couple of reads to make sense of it.

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.

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

#34
post #29

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

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

Thanks! I didn't see that, I'll give it a try again!

Re: Friendlier SQL with DuckDB

#35
post #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.

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.

That's why good database wrappers support referencing columns in result sets by column name. It's good practice.

Re: Friendlier SQL with DuckDB

#36
post #2

Lots 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.

BigQuery also supports trailing commas!

Re: Friendlier SQL with DuckDB

#37

That 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!

In this case it should probably be a JPEG? (Unless it has a transparent background and the site responds to the user's dark-mode setting? :) Also, this image looks like it almost certainly was a JPEG, at some point!)

Re: Friendlier SQL with DuckDB

#38
post #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.

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.

That's a problem with select * in general, not a problem with using EXCLUDE with select *. So that still doesn't explain why it's not in SQL to begin with.

Re: Friendlier SQL with DuckDB

#40
post #3

How 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…

I should add that we can read/write Apache Arrow as well!
Post reply on HN