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.
101–110 of 134 posts
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.
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
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.
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.
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…
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!).
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…
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
This isn't really the large, convincing example I was looking for btw.
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.
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 ;))
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.