Add ability to drop a materialized view and then recreate it, picking up from previous numbering

[armchairdj]

Use case:

• I have bunch of materialized views, each w/ multiple past versions.
• I'm updating the column type of a bunch of underlying data from :string to :citext so I can more easily do case-insensitive sorting.
• I'm unable to do those change_coumn :table, :field, :citext migrations because views depend on the columns I'm changing.

Current solution:

• Drop all the materialized views.
• Run my citext migrations.
• Delete all old sql files except the most recent one for each of the materialized views I need to resurrect.
• Delete any recent update_view migrations that haven't run in production yet so that when I deploy to production, those migrations don't blow up because the SQL files are missing.
• Rename the most recent SQL file to _001 for each view.
• Create brand-new materialized views with the same names as the old ones with create_view :view_name, materialized: true.(I had to do the deleting and renaming because create_view automatically uses the _001 definition. I couldn't use update_view because I previously dropped the views.)

Proposed solutions:

• Add a recreate_view :view_name migration method that allows me to pick up where I left off and retain all my historical sql files.
  • It would behave like create_view, but it would automatically increment and use the next sequential version suffix.
• Open to other suggestions.

[calebhearth]

Would something like this work?

def change
  drop_view :view_name, revert_to_version: 14
  change_coumn :table, :field, :citext
  create_view :view_name, version: 14
end