RunSQL Migration should accept psycogp2 sql.Composable object.

[suomenusko]

Generally, if we want to run raw SQL in the code, you do it the context of a cursor. If you have psycopg2 as your DB backend, in addition to passing cursor.execute a string, you can also pass an sql.Composable object, and it'll work.

However, if you are doing a RunSQL migration, you cannot use these, since the BaseDatabaseSchemaEditor execute method assumes it is a string (?). Specifically, it tries to explicitly casts it to a string, before passing sql to the cursor's execute. It seems like the line is there to account for non string objects, but str() won't convert Composable objects to the SQL statement correctly.

I'm not sure how reasonable it is to fix this, especially since I'm not too sure what collect_sql should be doing (it looks like sql being a string is pretty ingrained in the logic), and it's easy enough to fix this yourself by subclassing RunSQL, and calling the Composable's as_string method, but it seems like the schema editor's execute method should be agnostic towards the type you pass in, since all it really does is call the cursor's execute. With that said, I think it's fair to say this is more of a new feature than a bug.

[Mariusz Felisiak]

Thanks for the report, however this is ​documented behavior:

sql, and reverse_sql if provided, should be strings of SQL to run on the database. On most database backends (all but PostgreSQL), ...

I don't think that we should add any complexity here. If you want to use psycopg2.sql.Composable you can always do this via RunPython().