> Previous blog posts have covered DuckDB’s friendly SQL, including GROUP BY ALL and column selection using SELECT * EXCLUDE (...).
I love the idea of friendly SQL! I often create views with the same shape and would love it if UNION and UNION ALL accepted a list. But it's not in the standard so I've given up hope of it ever happening in PostgreSQL.
select * from view1 union all view2, view3, view4;
Would that work in MySql? Back in the day it used to do things like "natural join" that just figured out the the common columns to join, but i can't remember if it did that with union.
I'm excited about this and have some use cases already lined up but I'm continually worried about a grammar free-for-all and collisions as each extension author tries to modify the grammar. I'm hoping they already have something in place for that and I just haven't read about it yet. I'm concerned that you can load an extension and kind of mangle the interpretation of the syntax. Two author extensions could legitimately want conflicting parsers and there's no easy way to unload an extension in duckdb. Something like an explicit "GRAMMAR SQL" or "GRAMMAR GGSQL", etc would be nice.
> Previous blog posts have covered DuckDB’s friendly SQL, including GROUP BY ALL and column selection using SELECT * EXCLUDE (...).
I love the idea of friendly SQL! I often create views with the same shape and would love it if UNION and UNION ALL accepted a list. But it's not in the standard so I've given up hope of it ever happening in PostgreSQL.
Would that work in MySql? Back in the day it used to do things like "natural join" that just figured out the the common columns to join, but i can't remember if it did that with union.
I'm excited about this and have some use cases already lined up but I'm continually worried about a grammar free-for-all and collisions as each extension author tries to modify the grammar. I'm hoping they already have something in place for that and I just haven't read about it yet. I'm concerned that you can load an extension and kind of mangle the interpretation of the syntax. Two author extensions could legitimately want conflicting parsers and there's no easy way to unload an extension in duckdb. Something like an explicit "GRAMMAR SQL" or "GRAMMAR GGSQL", etc would be nice.
Told them?