Security benefits from a second opinion, are there flaws in my plan to hash & salt user passwords via postgresql?

Here is my plan, and goals:

Overall Goals:

• Security with a certain amount of simplicity & database-to-database transferrability, 'cause I'm no expert and could mess it up and I do开发者_如何学Cn't want to have to ask a lot of users to reset their passwords.
• Easy to wipe the passwords for publishing a "wiped" databased of test data. (e.g. I'd like to be able to use a postgresql statement to simply reset all passwords to something simple so that testers can use that testing data for themselves).

Plan:

Hashing the passwords

Account creation records the original email that an account is created with, forever.

• A global salt is used, e.g. "90fb16b6901dfceb73781ba4d8585f0503ac9391".
• An account specific salt, the original email the account was created with, is used, e.g. "my.account@example.com".
• The users's password is used, e.g. "password123" (I'll be warning against weak passwords in the signup form)

The combination of the global salt, account specific salt, and password is hashed via some hashing method in postgresql (haven't been able to find documentation for hashing functions in postgresql, but being able to use sha-2 or something like that would be nice if I could find it).

The hash gets saved in the database.

Recovering an account

To change their password, they have to go through standard password reset (and that reset email gets sent to the original email as well as the most recent account email that they have set).

Flaws?

Are there any flaws with this that I need to address? And are there best practices to doing hashing fully within postgresql?

---

I wouldn't make the user's data part of the salt. What if an administrator needs to change the user's email address for example (someone who doesn't know the user's password to be able to re-generate the hash). Use account creation timestamp or a random value stored on the record, or some other immutable user-specific value instead.