Add support for running SQL migrations as a regular migrator

[kvch]

This PR adds a new command called sqlmigrate. This lets users run regular SQL migration scripts as they are written in the files. It does not add any pgroll guarantees like avoiding locks or providing multiple schema versions.

The command is for people who want to use pgroll as a regular SQL migrator.

[andrew-farries]

I wonder if a different approach could work here. Rather than a new sqlmigrate command we allow the existing migrate command to work with .sql files too. So a migrations directory could look like:

01_some_migration.json
02_some_sql.sql
03_some_other_migration.json

I'm not sure what the start, complete, rollback workflow would look like for .sql files though.

It may be that supporting .yaml formats for migrations makes writing SQL in migration files less painful, in which case we wouldn't need to support standalone .sql files too.

[kvch]

I wonder if a different approach could work here. Rather than a new sqlmigrate command we allow the existing migrate command to work with .sql files too. So a migrations directory could look like:

01_some_migration.json
02_some_sql.sql
03_some_other_migration.json

Good idea.

I'm not sure what the start, complete, rollback workflow would look like for .sql files though.

Maybe we can expect migration_name.up.sql and migration_name.down.sql as SQL scripts, so start and rollback is taken care of. I would say complete is a no-op for this kind of operations. When a user runs an SQL migration, it is completed automatically after the script is finished. Also, having a down migration would not be a requirement.

It may be that supporting .yaml formats for migrations makes writing SQL in migration files less painful, in which case we wouldn't need to support standalone .sql files too.

The user request is that they want to run regular SQL migrations. So they do not have to write JSON/YAML/whatever format files. So I want to add support for SQL input as well.

[andrew-farries]

Maybe we can expect migration_name.up.sql and migration_name.down.sql as SQL scripts, so start and rollback is taken care of. I would say complete is a no-op for this kind of operations. When a user runs an SQL migration, it is completed automatically after the script is finished. Also, having a down migration would not be a requirement.

Having foo.up.sql and foo.down.sql makes sense to me.

With our current 'raw SQL' migations, we have the onComplete field which defaults to false. When true, the SQL is run on migration completion rather than start. We would probably lose the ability to do this if we go with the foo.up.sql and foo.down.sql approach.