61–70 of 124 posts
It would be even better if SQL had pipe syntax. SQL is amazing, but its ordering isn’t intuitive, and only CTEs provide a reliable way to preview intermediate results. With pipes, each step could clearly show intermediate outputs. Example: FROM orders |> WHERE order_date >= '2024-01-01' |> AGGREGATE SUM(order_amount) AS total_spent GROUP BY customer_id |> WHERE total_spent > 1000 |> INNER JOIN customers USING(custome…
CTE inspection is amazing. I spend too much time doing that manually.
input_data = duckdb.sql("SELECT * FROM read_parquet('...')")
step_1 = duckdb.sql("SELECT ... FROM input_data JOIN ...")
step_2 = duckdb.sql("SELECT ... FROM step_1")
final = duckdb.sql("SELECT ... FROM step_2;")
a fun function in duckdb (which I think they're using here) is `json_serialize_sql`. It returns a JSON AST of the SQL SELECT json_serialize_sql('SELECT 2'); [ { "json_serialize_sql('SELECT 2')": { "error": false, "statements": [ { "node": { "type": "SELECT_NODE", "modifiers": [], "cte_map": { "map": [] }, "select_list": [ { "class": "CONSTANT", "type": "VALUE_CONSTANT", "alias": "", "query_location": 7, "value": { "t…
I've used sqlglot to do this in the past, but doing it natively would be nice
I just watched the author of this feature and blog post give a talk at the DataCouncil conference in Oakland, and it is obvious what a huge amount of craft, ingenuity, and care went into building it. Congratulations to Hamilton and the MotherDuck team for an awesome launch!
Is that talk available online?
Earlier quoted context omitted.
Maybe in the next version they could also implement support for DROP, with autocorrect for the nearest (not yet dropped) table name.
Or, for extra fun, it auto completes to DROP TRIGGER and just drops a single random trigger from your database. It'll help counter automation fears by ensuring your DBAs get to have a wonderful weekend on payroll where, very much in the easter spirit, they can hunt through the DB looking for the one thing that should be there but isn't!
In DuckDB UI and MotherDuck. Awesome video of feature: https://youtu.be/aFDUlyeMBc8 Disclaimer: I’m a co-founder at MotherDuck.
a fun function in duckdb (which I think they're using here) is `json_serialize_sql`. It returns a JSON AST of the SQL SELECT json_serialize_sql('SELECT 2'); [ { "json_serialize_sql('SELECT 2')": { "error": false, "statements": [ { "node": { "type": "SELECT_NODE", "modifiers": [], "cte_map": { "map": [] }, "select_list": [ { "class": "CONSTANT", "type": "VALUE_CONSTANT", "alias": "", "query_location": 7, "value": { "t…
Can you go the other way? (E.g. edit the above and turn it back into SQL string) I've used sqlglot to do this in the past, but doing it natively would be nice
It would be even better if SQL had pipe syntax. SQL is amazing, but its ordering isn’t intuitive, and only CTEs provide a reliable way to preview intermediate results. With pipes, each step could clearly show intermediate outputs. Example: FROM orders |> WHERE order_date >= '2024-01-01' |> AGGREGATE SUM(order_amount) AS total_spent GROUP BY customer_id |> WHERE total_spent > 1000 |> INNER JOIN customers USING(custome…
I added a similar "get results as you type" feature to the SQLite integration in the Logfile Navigator (lnav)[2]. When entering PRQL queries, the preview will show the results for the current and previous stages of the pipeline. When you move the cursor around, the previews update accordingly. I was waiting years for something like PRQL to implement this since doing it with regular SQL requires more knowledge of the syntax and I didn't want to go down that path.
[1] - https://prql-lang.org [2] - https://lnav.org/2024/03/29/prql-support.html