This implies all "ops" should implement a to_diff_tuple which accepts no arguments and roughly is able to return the raw sql it should generate.
The two problems here are:
views currently accept a dialect to the function(s) which generate sql. this can probably be massaged away by having dialect specific impl of the normalization step that postgres does (inside the postgres-specific view).
some of the ops' to_sql functions produce lists of strings instead of just a string. the to_diff_tuple interface seems to want a single statement. Either we concat them for this, and it doesn't exactly match the migration, or we normalize them out into separate ops (i'd rather not), or we combine the sql statements into a single execute (i'd rather not)
This implies all "ops" should implement a
to_diff_tuplewhich accepts no arguments and roughly is able to return the raw sql it should generate.The two problems here are:
to_sqlfunctions produce lists of strings instead of just a string. theto_diff_tupleinterface seems to want a single statement. Either we concat them for this, and it doesn't exactly match the migration, or we normalize them out into separate ops (i'd rather not), or we combine the sql statements into a single execute (i'd rather not)