Ah, that theoretical answer does fill in one missing link for me. I kept wondering how you could detect even a trivial modification of a standard hashing algorithm (say, reversing the hash) if all you had to look at was its outputs. It seemed like a massive search problem through the space of all possible modifications, though no doubt there exist sophisticated techniques to apply. But if you have some input/output pairs, the problem seems entirely more tractable. Even I can begin to imagine how one might tackle that.

The point you and others make that if the database is compromised then the code almost certainly is too, is clearly the best answer though. I am now prepared for the next time I encounter my interlocutor at extended family dinners!

In my house we have a rule that we don't discuss password hashing at the dinner table

Cryptographically, you can address the problem you've set out for yourself simply by hashing a 128 bit random number along with the password, and keeping that number a secret. If attackers can get your code, it doesn't matter how you obscure your hash, because they'll have the algorithm. But through trial and error, an attacker might figure out how you tweaked an algorithm; all the atoms in the solar system (or something like that, I can never remember) could be computers trialing and erroring against a 128 bit random number and they'd never figure it out.

128 bits is a big number/keyspace but the solar system is no lightweight, either.

    2^128 = 3.4028E38 
    solar mass = 1.9884E30 kg or about 9E56 atoms. 

You don't need to get down to atoms, you could be crunching 128 bit keys on a single AWS dyson1-medium instance.

256 bits is the one where the hosting costs start getting not merely planetary but intergalactic.

    2^256 = 1.1579E77
    atoms in Milky Way = 2.9E76 atoms