gh-ost currently only allows providing ALTER statements. It would be helpful if we can directly define the goal-state table rather than the list of ALTER statements needed to achieve it.
This is especially helpful for platform products where there are implementation details that may need to change across the entire platform. Instead of needing to determine the sequence of ALTERs for every change, one can simply provide the new table definition and have gh-ost use it in CreateGhostTable.
It would be the caller's responsibility to ensure that the table definition is compatible with backfilling and cutting over. gh-ost would continue doing simple internal validations similar to the ALTER flow.
Enhancement
gh-ost currently only allows providing ALTER statements. It would be helpful if we can directly define the goal-state table rather than the list of ALTER statements needed to achieve it.
This is especially helpful for platform products where there are implementation details that may need to change across the entire platform. Instead of needing to determine the sequence of ALTERs for every change, one can simply provide the new table definition and have gh-ost use it in CreateGhostTable.
It would be the caller's responsibility to ensure that the table definition is compatible with backfilling and cutting over. gh-ost would continue doing simple internal validations similar to the ALTER flow.