Change History

Yes, this is currently by design; when South adds the field, it has to do with with a DEFAULT clause (to fill in existing rows), but to match Django's syncdb schema, it will then modify the column to not have a default, using alter_column.

Since alter_column doesn't look at the database before executing, it will always execute the same alter statements, since doing them repeatedly is harmless. I agree that it means more database locks, but to be fair, if you're betting on the migration finishing three seconds faster than normal, or are trying to do it on a very busy live site, you're probably either doing it wrong, or have other issues.

Basically, I'd rather keep this around and have one set of codepaths than unnecessarily complicate things. If you have convincing arguments otherwise, I'm happy to re-open the ticket and fix it.

All of these are unnecessary , however this statement in isolation will cause a table rewrite on postgres, i.e. the entire table will need to be read and rewritten to disk causing a lot of disk IO and potentially requiring 2x the size of the table on disk

ALTER TABLE "people_person" ALTER COLUMN "name" TYPE text

Note that using the --db-dry-run --verbosity=2 settings show that only the

ALTER TABLE "people_person" ADD COLUMN "name" text NULL;

Will be executed, when in-fact the second alter table statement is also issued.

The problem here is that South doesn't know that the column is already the right type; we do virtually no database introspection, as that keeps the code a lot more sane.

It is inconvenient that the statement causes Postgres to rewrite the table - that sounds like something they could fix - but without a major rewrite of South's code, I just don't see what we can do here.