The way you handle breaking changes in SQL is views, not migrations; the latter is only appropriate single applications abusing SQL as a data store[0].
In code, if you want to handle a breaking change transparently, you don't need the moral equivalent of a linker fix-up table. You need to keep the old definition around and redirect it to the new function. This can be as simple as having, say, the old version of your code wrap something in a list or closure and then call the new version. In languages with overloading, this can be done transparently; in others you'd have to give the new function a new name. Maybe API versioned symbols and a syntax for them is what you would want?
[0] The original idea with SQL is that multiple applications would store data in the same place in a common format you could meaningfully interchange.
In code, if you want to handle a breaking change transparently, you don't need the moral equivalent of a linker fix-up table. You need to keep the old definition around and redirect it to the new function. This can be as simple as having, say, the old version of your code wrap something in a list or closure and then call the new version. In languages with overloading, this can be done transparently; in others you'd have to give the new function a new name. Maybe API versioned symbols and a syntax for them is what you would want?
[0] The original idea with SQL is that multiple applications would store data in the same place in a common format you could meaningfully interchange.