Live data from Hacker News

Friendlier SQL with DuckDB

duckdb.org

101–110 of 134 posts

Re: Friendlier SQL with DuckDB

#101
On the topic of friendlier SQL, there was a feature LINQ to SQL added to (and I believe removed from) .Net

It was basically syntactic sugar for a persistence API.

Instead of "select bar from foo" it used a "from foo select bar" type of syntax.

This was rather nice from a code completion perspective.

Re: Friendlier SQL with DuckDB

#102
post #86

I would go even further and say that "GROUP BY ALL" and "ORDER BY ALL" should be implied if not provided in the query. EDIT: Typo

We thought about that, but particularly with `GROUP BY ALL` the problem is that we would get different results from SQLite. When a column is not mentioned in the `GROUP BY` clause in SQLite it automatically pushes a `FIRST` aggregate over that column. So for example, the following query:

  SELECT city, COUNT(*)
  FROM customers
In SQLite is transformed into:

  SELECT FIRST(city), COUNT(*)
  FROM customers
In our experience this is not a good default since it is almost never what you want, and hence we did not copy this behavior and instead throw an error in this situation. However, if we were to add an implicit `GROUP BY ALL` our transformed queries would now diverge, i.e. we would transform the above query to:

  SELECT city, COUNT(*)
  FROM customers
  GROUP BY city
Having diverging query results from SQLite on quite basic queries would confuse a lot of newcomers in DuckDB, and potentially cause silent problems when query semantics change when switching databases.

We could definitely add a flag to enable this behavior, however.

Re: Friendlier SQL with DuckDB

#104

Interesting additions! On using column aliases in predicates, what if my alias exists in the source as well, what takes precedence? I feel like this can become a bit confusing either way.

For compatibility, the original column in the data source takes precedence. That's how other DBs handle things so we wanted to stay standard where it made sense!

Re: Friendlier SQL with DuckDB

#105
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

Not just SQL, trailing commas are stupidly useful and convenient, so as far as I'm concerned every language should have them. To be fair, a decent amount of them have implemented them (I was pleasantly surprised by GCC C), but there are still notable holdouts (JSON!).

Re: Friendlier SQL with DuckDB

#106
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…

Are leading commas allowed? Because otherwise, you've just traded out the inability to comment out the last element for the inability to comment out the first. I never understood this convention.

Re: Friendlier SQL with DuckDB

#107
post #73

Earlier quoted context omitted.

(nothing to do with DuckDB but..) SQL is complex enough, and allowing this (and acyclically as mentioned below) would do my $%^& nut implementing it. But I know a user requirement when I hear one, so can you give me an large, real example of where allowing this would make things easier? That would be mega helpful, ta

for example select id, count(...something complicated) as complicated_count from .... order by complicated_count would help

SQL already supports "order by complicated_count". Did you mean group by?

This isn't really the large, convincing example I was looking for btw.

Re: Friendlier SQL with DuckDB

#108

Earlier quoted context omitted.

'ORDER BY 2' would work here, but using the named column is a lot nicer.

Wow, TIL. Great tip for those random one-off queries you have to bash out when investigating a problem.

Please never let this vile shortcut work its way into your production code.

Re: Friendlier SQL with DuckDB

#109
post #93

Earlier quoted context omitted.

(nothing to do with DuckDB but..) SQL is complex enough, and allowing this (and acyclically as mentioned below) would do my $%^& nut implementing it. But I know a user requirement when I hear one, so can you give me an large, real example of where allowing this would make things easier? That would be mega helpful, ta

What does "do my $%^& nut" even mean? (looks like Perl ;))

:-) English idiom. Nut = head. Doing my head in, basically.

Re: Friendlier SQL with DuckDB

#110
I've been experimenting with DuckDB using modified Mondrian OLAP engine and it looks very promising so far, performance wise.

A questions I have to author, or anyone using: Is there a easy way to transfer whole Postgres DB into DuckDB so I can do some tests with actual client data? I could export each table by hand and reimport it, but that is kind of painful.

Post reply on HN