Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Friendlier SQL with DuckDB

duckdb.org

Post reply on HN
Print view View original

41–50 of 134 posts

Re: Friendlier SQL with DuckDB

#41

Post by flakiness »

snidane wrote: post #10
roncohen wrote: 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…

Allow referencing columns defined previously in the same query would make duckdb competitive for data analytics. Without that one has to chain With statements for just the tiniest operations. select 1 as x, x + 2 as y, y/x as z;

There is a bug for that and it looks someone is even working on it. https://github.com/duckdb/duckdb/issues/1547

Re: Friendlier SQL with DuckDB

#42

Post by tracker1 »

andai wrote: post #37
1egg0myegg0 wrote: post #28

Earlier quoted context omitted.

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

The color palette is pretty limited, so using something that can have a specific/limited palette (say 48-64 color in this case) is probably going to have a better result than jpeg. Also, optimizing for display size would take it further still. Alpha transparency support is also a bonus for png over jpeg.

Re: Friendlier SQL with DuckDB

#45

Post by ergocoder »

tosh wrote: 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?

Sqlite's SQL is severely limited.

If you want to do something a bit more complex, you will have a bad time. Hello! With recursive.

Re: Friendlier SQL with DuckDB

#46

Post by OskarS »

1egg0myegg0 wrote: post #9
tosh wrote: 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…

One of SQLite's most appealing aspects to me is using it as an application file format, as described in this article: https://www.sqlite.org/appfileformat.html

How does DuckDB compare in that aspect? Does it have the same kind of guarantees of robustness, incorruptibility and performance (especially reading/writing binary blobs) that SQLite does?

In any case: DuckDB looks great, nice work! Good to have more players in this space!

Re: Friendlier SQL with DuckDB

#47

Post by nlittlepoole »

Oxodao wrote: 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

Ran into some similar issues with those bindings. We switched to using the ODBC drivers and its been great. Those are official and we just use an ODBC library in go to connect

Re: Friendlier SQL with DuckDB

#48

Post by karmakaze »

flakiness wrote: post #41
snidane wrote: post #10

Earlier quoted context omitted.

Allow referencing columns defined previously in the same query would make duckdb competitive for data analytics. Without that one has to chain With statements for just the tiniest operations. select 1 as x, x + 2 as y, y/x as z;

There is a bug for that and it looks someone is even working on it. https://github.com/duckdb/duckdb/issues/1547

There's also no need to make it left to right usage, as long as it's acyclic:

  select y-2 as x, 3 as y, y/x as z;

Re: Friendlier SQL with DuckDB

#49

Post by aerzen »

If anyone is interested in improvements to SQL, checkout PRQL https://github.com/prql/prql, a pipelined relational query language.

It supports:

- functions,

- using an alias in same `select` that defined it,

- trailing commas,

- date literals, f-strings and other small improvements we found unpleasant with SQL.

https://lang.prql.builders/introduction.html

The best part: it compiles into SQL. It's under development, though we will soon be releasing version 0.2 which would be "you can check it out"-version.

Re: Friendlier SQL with DuckDB

#50

Post by eyelidlessness »

Often efforts and articles like this feel like minor affordances which don’t immediately jump out as a big deal, even if they eventually turn out to be really useful down the road. Seeing the article title, that’s what I expected. I did not expect to read through the whole thing with my inner voice, louder and more enthusiastically, saying “yes! this!” Very cool.
Post reply on HN