So, I'm cool with using a per-user salt to hash my users' passwords. However, there's one piece of advice in the accepted answer:
Do not use a separate column for the salt.
This doesn't make sense to me. If I'm just catenating the hash and salt and putting them in the same column, surely that's semantically equivalent to two separate columns? In which case, that's just security-by-obscurity, no?
It's easier to use a separate column to store the salt (as long as it's per-user). Why shouldn't I?
I think the second part of the first answer (the part about "dynamic salt") in that thread gives you an answer like you expect: Generate a random, per-user salt and store that with the hashed password. This is exactly what UNIX passwd (and later shadow) files have done for decades.
There's some confusion in that thread about what exactly salt is. Some replies take a very general definition along the lines of "any known text mixed into a password before performing a one-way hash". There are lots of reasons to mix known text and secret text before performing a one-way hash, and obviously the treatment of the known text in such cases would depend on the algorithm. For an example, look at http://en.wikipedia.org/wiki/CRAM-MD5 which avoids having the user send their password over the network at all by having them hash it with a "salt" specified by the server.