Hi apologist. How was the woodwork? Your exact comment was why I wrote mine.
You could write predicates over non-existent columns:
root=> SELECT * FROM t
WHERE definitely_not_a_column = 4;
SELECT * FROM t WHERE 4 = 5;
a | b
---+----
5 | 6
(1 row)
System.out.println(((Integer)4).compareTo((Integer)5));
> -1
So it's SELECT FROM t WHERE true;
Now, let's get busy blaming Jepsen for using the tool wrong.
> therefore that whole WHERE clause doesn't exist either
No, therefore the condition is unsatisfiable and equivalent to WHERE FALSE. And that's letting you ignore the SQL spec, which says the query is invalid and should return "Column not found" because the column name cannot be resolved.
> We're comparing 4 and 5. Precedent?
I really hope you're trolling, for your own sake.
The explanation is more damning than the devex.
The condition is unsatisfiable, and the engine went ahead and gave a 0-warning result?
Are you claiming that 4 = 5?
I'm claiming that
1) It would be no more fucked up than anything else that has been grandfathered into our tools.
2) If it already had mass adoption in the market, people would jump onto this thread to explain to me that I just don't understand the brilliant semantics behind language of why 4 = 5.
Apologist for what?