https://github.com/particledbai/jepsen/issues/18 is utterly humiliating. I can’t believe they kept going after getting that report. I would die of shame.

(Edit for clarity: this is quoted from the linked article)

  You could write predicates over non-existent columns:

  root=> SELECT * FROM t
         WHERE definitely_not_a_column = 4;
   a | b
  ---+----
   4 | 5
  (1 row)
  Or ask if 4 = 5

  root=> SELECT * FROM t WHERE 4 = 5;
   a | b
  ---+----
   5 | 6
  (1 row)

Good on them for being good sports I guess, but after reading this I would never touch a piece of software built by anyone involved with this company. The sheer hubris of their claims combined with the specific reality of their broken garbage software (with the contradicted marketing claims and hallucinated documentation) is literally breathtaking.

It must have been darkly amusing to see all these defect tickets coming in, only for them to frantically shovel each one to increasingly overworked LLM agents to apply pig-lipstick while the humans in charge oh-so-slowly start to realize their software quality is not quite what their glazing agents had been telling them and that what they have on their hands is basically sub-mongo-quality slop. What a world we live in, huh?

▲ mrkeen 3 hours ago | parent | next [-]

I won't push back on it being garbage, but I would suggest that if enough people did it that way it would be the new normal, and apologists would fall out of the woodwork, e.g. [1]

I complain that mainstream SQL engines have no problem returning less than the total number of rows if you first query WHERE column = NULL and then query WHERE column <> NULL. Your example queries remind me of that.

[1] https://medium.com/dailyjs/the-why-behind-the-wat-an-explana...

▲ semiquaver 3 hours ago | parent | next [-]

  > WHERE column = NULL and then query WHERE column <> NULL

With respect, your statement seems to indicate that you simply haven’t heard of or don’t understand the three-valued-logic semantics behind SQL.

NULL means what it means and is conceptually foundational to SQL. Comparing it to anything returns UNKNOWN, the “third value” besides true and false. And WHERE needs a TRUE predicate. So your implied fault that they “have no problem“ really is just a matter of you not understanding the tool you are complaining about.

To match against the NULLness of a value you must use special purpose operators. In this case

   WHERE column IS NULL OR column IS NOT NULL

▲ mrkeen 2 hours ago | parent [-]

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;

Cool, definitely_not_a_column doesn't exist, so therefore that whole WHERE clause doesn't exist either, so the real query is SELECT FROM t.
SELECT * FROM t WHERE 4 = 5; a | b ---+---- 5 | 6 (1 row)
We're comparing 4 and 5. Precedent?
System.out.println(((Integer)4).compareTo((Integer)5)); > -1
What happens when you treat -1 as a bool? The following languages agree that -1 is true: C, C++, JS, Python, PHP, Ruby, Perl, Lua, R.

So it's SELECT FROM t WHERE true;

Now, let's get busy blaming Jepsen for using the tool wrong.

	▲	debugnik an hour ago \| parent [-]
		> 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.

▲ CodesInChaos 3 hours ago | parent | prev [-]

I am rather receptive to the argument that SQL is a fractal of bad design. But complaining that SQL engines implement well known SQL semantics according to spec is silly.

▲ 4 hours ago | parent | prev [-]

[deleted]