3 ms·

The author of this seems to be surprised that the DB doesn't just sort things (which could be billions of rows) automatically. SQL deals with "sets", which are

The author of this seems to be surprised that the DB doesn't just sort things (which could be billions of rows) automatically. SQL deals with "sets", which are unordered, and the user needs to specify the order by if they need sorted output. I think this is an excellent design.

GeertJohan 6y ago
I'm not sure thats a point the author is trying to make. To which example are you refering?
benesch 6y ago
You're not looking at the examples closely enough, if that's your takeaway. I assure you they are much weirder than forgetting to specify an ORDER BY clause and expecting sorted output.
JohnBooty 6y ago
SQL deals with "sets", which are unordered, and the user needs to specify the order by if they need sorted output. I think this is an excellent design. Well-said, and I completely agree. However, I'm not sure that the author is complaining about SQL, so much as he is kvetching about some of the weird-looking things one needs to deal with while "working on a postgres-compatible query compiler."
ben509 6y ago
> SQL deals with "sets" SQL deals with tables, and all operations are working on tables. However... these tables are bags of rows, not sets, as evidenced by: 1. "distinct" transforms bags into sets 2. "union all" preserves bags 3. the ability to create a table with no primary key, allowing entirely duplicate rows in a table 4. the ability to select columns not including a primary key, allowing duplicate rows in the resulting table > ... which are unordered While (base) tables themselves guarantee no order: 1. every "select" is itself returning a table, which can absolutely have an order. 2. a "view" is a (derived) table, and it can guarantee an order 3. aggregate functions rely on ordering > I think this is an excellent design. Your approach would be an excellent design.

GeertJohan 6y ago

I'm not sure thats a point the author is trying to make. To which example are you refering?

benesch 6y ago

You're not looking at the examples closely enough, if that's your takeaway. I assure you they are much weirder than forgetting to specify an ORDER BY clause and expecting sorted output.

JohnBooty 6y ago

SQL deals with "sets", which are unordered, and the user needs to specify the order by if they need sorted output. I think this is an excellent design. Well-said, and I completely agree. However, I'm not sure that the author is complaining about SQL, so much as he is kvetching about some of the weird-looking things one needs to deal with while "working on a postgres-compatible query compiler."

ben509 6y ago

> SQL deals with "sets" SQL deals with tables, and all operations are working on tables. However... these tables are bags of rows, not sets, as evidenced by: 1. "distinct" transforms bags into sets 2. "union all" preserves bags 3. the ability to create a table with no primary key, allowing entirely duplicate rows in a table 4. the ability to select columns not including a primary key, allowing duplicate rows in the resulting table > ... which are unordered While (base) tables themselves guarantee no order: 1. every "select" is itself returning a table, which can absolutely have an order. 2. a "view" is a (derived) table, and it can guarantee an order 3. aggregate functions rely on ordering > I think this is an excellent design. Your approach would be an excellent design.