some that create FUNCTION/TRIGGER (similar to 00000000000000_diesel_initial_setup)
some that do the "normal" migrations, creating or alter TABLE etc.
The problem is when there is a bug in the 1. kind. While theoretically it would be possible to simply modify the migrations file, in how the migrations currently works, the bug won't get fixed in existing installations.
The "proper" current way, as I understand it, is to drop the old FUNCTION, and create a new one (with all same but the bug fixed), but in down I would need to restore the old function (with bug). This might make sense if the code is tightly related to the data it is working on (and the bug must be present to work with the old data), but this is massive overkill (duplication of every FUNCTION) if the functions are not related to the data (or work with any version of the migrations).
This use case could be probably solved with #2085, but probably there are more elegant ways to solve the problem with bugs in FUNCTION specifically.
We have two different kinds of migrations,
The problem is when there is a bug in the 1. kind. While theoretically it would be possible to simply modify the migrations file, in how the migrations currently works, the bug won't get fixed in existing installations.
The "proper" current way, as I understand it, is to drop the old FUNCTION, and create a new one (with all same but the bug fixed), but in down I would need to restore the old function (with bug). This might make sense if the code is tightly related to the data it is working on (and the bug must be present to work with the old data), but this is massive overkill (duplication of every FUNCTION) if the functions are not related to the data (or work with any version of the migrations).
This use case could be probably solved with #2085, but probably there are more elegant ways to solve the problem with bugs in FUNCTION specifically.