All of these operations are available from
You can create a PostgreSQL extension in your database using a migration file. This example creates an hstore extension, but the same principles apply for other extensions.
from django.contrib.postgres.operations import HStoreExtension class Migration(migrations.Migration): ... operations = [ HStoreExtension(), ... ]
The operation skips adding the extension if it already exists.
For most extensions, this requires a database user with superuser privileges.
If the Django database user doesn’t have the appropriate privileges, you’ll
have to create the extension outside of Django migrations with a user that has
them. In that case, connect to your Django database and run the query
CREATE EXTENSION IF NOT EXISTS hstore;.
In older versions, the pre-existence of the extension isn’t checked.
hstore extension and also sets up the connection to
interpret hstore data for possible use in subsequent migrations.
If you need to filter or order a column using a particular collation that your
operating system provides but PostgreSQL does not, you can manage collations in
your database using a migration file. These collations can then be used with
db_collation parameter on
TextField, and their subclasses.
For example, to create a collation for German phone book ordering:
from django.contrib.postgres.operations import CreateCollation class Migration(migrations.Migration): ... operations = [ CreateCollation( 'german_phonebook', provider='icu', locale='und-u-ks-level2', ), ... ]
Creates a collation with the given
deterministic parameter to
False to create a
non-deterministic collation, such as for case-insensitive filtering.
Removes the collations named
When reversed this is creating a collation with the provided
deterministic arguments. Therefore,
required to make this operation reversible.
Non-deterministic collations are supported only on PostgreSQL 12+.
PostgreSQL supports the
CONCURRENTLY option to
CREATE INDEX and
DROP INDEX statements to add and remove indexes without locking out writes.
This option is useful for adding or removing an index in a live production
AddIndex, but creates an
index with the
CONCURRENTLY option. This has a few caveats to be aware
of when using this option, see the PostgreSQL documentation of building
CONCURRENTLY option is not supported inside a transaction (see
PostgreSQL supports the
NOT VALID option with the
statement to add check constraints without enforcing validation on existing
rows. This option is useful if you want to skip the potentially lengthy scan of
the table to verify that all existing rows satisfy the constraint.
To validate check constraints created with the
NOT VALID option at a later
point of time, use the
See the PostgreSQL documentation for more details.
AddConstraint, but avoids
validating the constraint on existing rows.
Scans through the table and validates the given check constraint on existing rows.
ValidateConstraint operations should be
performed in two separate migrations. Performing both operations in the
same atomic migration has the same effect as
AddConstraint, whereas performing
them in a single non-atomic migration, may leave your database in an
inconsistent state if the
ValidateConstraint operation fails.