> PostgreSQL supports most of the major features of SQL:2023. Out of 177 mandatory features required for full Core conformance, PostgreSQL conforms to at least 170. In addition, there is a long list of supported optional features.
Clickhouse is simply a joke in comparison. No basic cursor support, no transactions, incomplete comparison operators, no single-row SELECT with GROUP BY and HAVING clauses grouped views, no procedures, no anti-joins or WHERE EXISTS, for that matter. The list goes on... it's basically impossible to write SQL to any degree of sophistication in Clickhouse.
Exists, but without Correlated Sub query part, which is honestly a joke because of how subpair performance it usually have compared to other alternatives.
Can you remind, does SQL:2023 standard finally allow you to use DISTINCT keyword in WINDOW functions?
Or people still forced to do horrible hacks with correlated subqueries or joins to do extremely simple thing like count Distinct in running window of X days?
> it's basically impossible to write SQL to any degree of sophistication in Clickhouse.
One thing that I have noticed confuses a lot of people is "timeseries joins" (I don't know the real term for this) I'm talking about where there is no "one to one" match between keys in the two tables.
I'm a non software type of engineer in my world a lot of tables are structured as timeseries data (such as readings from a device or instrument) which uses timestamp as a key.
Then we have other tables which log event or batch data (such as an alarm start and end time, or Machine start/machine stop etc).
So a lot of queries end up being of the form
Select A.AlarmId, B.Reading, B.Timestamp from Alarms A, Readings B where A.StartTime >= B.Timestamp and A.EndTime < B.Timestamp
A lot of people seem to have problems grasping these kinds of joins.
Cool use case. They're just called "non equi-joins" - because the join condition is an inequality. In general a join produces a row in the output table for each (left, right) pair of rows from the input tables that satisfies the join condition. It's just so common for joins to use a simple equality condition, where one or both sides is a unique id for its table, and people don't as often encounter joins where one input row can inform multiple output rows.
* Explain the difference between a database and a database manager.
* Write SQL to select, filter, sort, group, and aggregate data.
* Define tables and insert, update, and delete records.
* Describe different types of join and write queries that use them to combine data.
* Use windowing functions to operate on adjacent rows.
* Explain what transactions are and write queries that roll back when constraints are violated.
* Explain what triggers are and write SQL to create them.
* Manipulate JSON data using SQL.
* Interact with a database using Python directly, from a Jupyter notebook, and via an ORM.