orthogonal migration support (multiple migrations).

[hsyed]

This one is connected to #6. We are building a JS framework ontop of plv8, one of the things we need to do is manage migrations for parts of the JS separately from the schema elements. The JS would be upserted into the tables when a version bump occurs.

For this I need to manage versions -- tern's version table does not contain a migration name.

If we can add a name field to the table it would enable the following method:

func (m*Migrator) UserMigration(name string, currentVersion uint8, um function(*pgx.Conn) error) (previous uint8, err error) {
   // The user function is reached if currentVersion > version in db table.
   // if this returns no error than the db version table row with name is updated to currentVersion
}

The version table could be migrated to contain a name field and the legacy nameless migrations could be given the name "default" ?

I know this is probably crossing the use-case boundaries. But, since pgx does so much more than an average pg driver -- perhaps it makes sense.

[jackc]

If I understand correctly you are trying to have multiple separate streams of migrations? How many separate streams do you need?

[hsyed]

I couldn't say for sure need to get into the design of the framework. From a design perspective perhaps 2 for now -- both of these migrations are upsertable/updateable. One for the JS stored procedure layer and one for the system javascript that is loaded by the SP's.

I suppose I could merge the migration streams together and just use the versionTable string to create a second versionTable.

But,I don't think I'd be able to use AppendMigration as is -- without a hack of some sort ? Bumping the versions would lead to holes when applying the migrations to a new db.

Postgres is so powerful though that separate orthogonal migration streams are a good feature to have imo.

[hsyed]

I won't be needing what I proposed above right now.. The issue can can be closed unless you want to pursue it.