That would be the same if you had a plain-text password column on the user table.

If the site stores plaintext passwords then you can do a single database call - "fetch record where username='foo' and password='letmein' ". Doing that means if either the username or password is incorrect you get no records back and don't know why.

However...

the hashed password comparison doesn't match, you still don't really know if it was the username or password that's wrong, for sure. The password might be correct for sar, and it's the username that has a typo.

That's true if the site is just hashing, but that's only a small step up in security terms from just storing as plain text, and no site should be doing it.

Instead passwords should be salted, which is like taking a password and adding an extra random string to it. That means the record in the db becomes

user='sat' salt='8m072b3s5' password=hash(bestpassword8m072b3s5)

Because of that salt you can't just check for "user='sat' and password=hash(bestpassword)" in one go, you have to first load the user, then add their salt to the password, then check if the password is correct.