Right now, we might do something like
password varchar(72), when defining a password column, with for example BCrypt. But there's a lot of folks that don't do this very effectively. Maybe they just put the plaintext, or a single unsalted md5 hash, or some other terrible strategy.
But virtually all these offenders still use databases. So why isn't this kind of functionality baked into databases? Something like
mypass password('BCrypt:10'), and accessed like
INSERT INTO people(name, mypass, other_data) VALUES(?, ?, ?) which would take the plaintext password from the user and pass it to the table. But the table would store the appropriate BCrypt hash value. Then, we could do something like
SELECT other_data FROM people WHERE name = ? AND mypass = ? - this again would take the plaintext from the user logging in, but load the salt and perform the analysis to determine of the the password was a success or not.
When it comes to storing data, we go with databases instead of flat files or what have you because they're reliable, tested, and simple (in comparison to rolling our own). Since it's clear that in the wild there are innumerable where password storage is unreliable and untested, why is this sort of data storage not undertaken by the database itself?