Good *lord* . You’re distributing malware and feeding a spammer, knowingly, and you don’t intend to clean it up?

Ugh.

I’m done helping you, sir. Enjoy being unable to handle extremely simple topics in SQL while giving advice to the public.

Yes, Tim, it does. That you haven’t tried it in any other SQL engine, and that you don’t appear to understand what undefined behavior is, is pretty not-compelling.

Try it in Postgres. Wrong rows. Try it in Oracle. Right rows. Try it in MSSQL. Wrong rows.

Why? Because the query is wrong, and the problem just happens not to fire under MySQL or Oracle because of the order their optimizers give.

It’s wrong, Tim, whether you understand it or not.

> You provided an example query (select * from foo as A left join foo as B on A.id = B.id where A.col To be honest when I examine it I don’t see how it would solve this problem

G’lord.

You provided an example query (select * from foo as A left join foo as B on A.id = B.id where A.col < B.col and B.id is null; ) and I am yet to get it to work. To be honest when I examine it I don't see how it would solve this problem, but that could just be my inexperience.

Yeah, you’re giving advice in public, then posting it to link sharing sites. If you want to mince words and suggest that that’s something other than you pretending to be an expert, fine; the point remains, you really should not be giving advice.

“I’m not sure you read the post correctly because the solution (which is very clearly marked) uses neither GROUP BY nor ORDER BY.”

I read the post correctly, sir. Perhaps you should re-read your own writing. That criticism was aimed at this verbatim quote:

““What?” I thought, “That’s the least recent log for task_id 1!”. Then it struck me, “Oh, ORDER BY is performed after GROUP BY. Now what do?” “

What I was trying to point out is that you had reacted to undefined behavior not going the way you expected by guessing, incorrectly, that the undefined behavior was just defined some other way. (Note that that’s where you leave the topic, too.)

The answer, of course, is something other than to accuse people who provide legitimate technical solutions to your problem of not having read correctly.

“In my opinion, this is non-trivial because it requires a subquery”

That’s … kind of ridiculous, you know. That’s like saying “this C++ program is non-trivial because it requires a function.”

I mean come on, that’s about as basic as SQL gets.

What I actually asked you, of course, was “what is trivial to you?”

The phrase “non-trivial” is how a trivial programmer makes themselves feel like any limitation they find in their own skillset reflects something deep and difficult about a language.

Let me remind you: you’re looking for a set of rows with high numbers. That’s _as_ _simple_ _as_ _production_ _SQL_ _ever_ _gets_.

That’s the *definition* of trivial SQL.

I’ll ask you again. Please this time focus on what I’m actually asking you.

What, in your mind, constitutes something significantly more trivial than

select * from foo as A left join foo as B on A.id = B.id where A.col < B.col and B.id is null;

I mean, Christ, really? That's non-trivial to you?

Please stop attempting to give advice on ridiculously simple topics in SQL in public, regardless of whether you feel your tone means that people shouldn't be taking you seriously, then explaining why one of the very simplest relational queries possible in the entire language is somehow non-trivial because it's not just a raw select.

Seriously, the solution you gave is dangerously incorrect; it can give extremely wrong results.

You *need* to not try to explain how to do SQL in the future. You're going to screw someone badly.

I’ll have a look at self-joins on your advice.

In my opinion, this is non-trivial because it requires a subquery or, as you suggested, a column-wise self join. Such queries don’t fall under the ‘trivial’ category, at least not in my mind.

The appropriate approach is an atomic comparison, which will always give the correct answer regardless of implementation. One such approach – the default in this situation – is a column-wise self join comparing left to right such that right’s value is null (that is, “give me all the rows such that for the comparison there is no valid right side,”) which will always give the appropriate highest value (and in far better time besides.)

Hilariously, the *correct* answer is also provided on the MySQL page you linked. It’s just that when you get bad advice from the MySQL manual, it’s usually MySQL specific.

Please leave the SQL advice to people who understand SQL in the future.

Thanks.

(Groupwise maximums are non-trivial SQL now? Good lord, what’s trivial to you?)