This seems a working solution. Except that you are correct, the presented code would fail on function change
You can use runOnChange attribute on the changeset tags defining the functions and the like (and / or runAlways, just to be on the safe side). If stored procedures are written in an idempotent way (e.g. CREATE OR REPLACE in Postgres, or DROP IF EXISTS ... ; CREATE ... in SQL Server) then the code would just run on change and it would be possible to use neat git diffs to see the actual change.
Problem here is that it becomes a bit hard to see which changes have been applied to the database and which weren't.
The only thing you know is that "when sproc A was last replaced at <timestamp>, the SQL code hashed to a value of <hash>".
Since you don't have a ready hash of the resulting changeset, it might be a bit hard to identify in case of any discrepancies. This could be a moot point if you have other ways of tracking deployed versions, of course...