#34898: Adding non-deterministic collations to unique CharFields crashes on
PostgreSQL.
-------------------------------------+-------------------------------------
     Reporter:  Mariusz Felisiak     |                    Owner:  Tom
                                     |  Carrick
         Type:  Bug                  |                   Status:  assigned
    Component:  Migrations           |                  Version:  4.2
     Severity:  Normal               |               Resolution:
     Keywords:  PostgreSQL           |             Triage Stage:  Accepted
  collation                          |
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Peter Thomassen):

 * cc: Peter Thomassen (added)

Comment:

 This is a regression caused by the commit which removes
 django.contrib.postgres.fields.CIText/CICharField/CIEmailField/CITextField
 (04eb1b4567c96ccb167c16a95ca12c336b0c791b).

 Using the code immediately before that commit (i.e., using
 6e4e5523a8f40b63f3e74889266a7d638f6364dc), the ALTER statement setting the
 collation is preceded by `DROP INDEX IF EXISTS
 "desecapi_user_email_fa6ced42_like"`.

 When applying the next commit (04eb1b4567c96ccb167c16a95ca12c336b0c791b),
 this `DROP INDEX` statement is gone, and the ALTER statement then causes
 `nondeterministic collations are not supported for operator class
 "varchar_pattern_ops"`.

 We used to have a unique CIEmailField. When that was deprecated, we
 created a migration that turns this into a standard EmailField, but a
 case-insensitive collation; the uniqueness properties were not changed.
 See: https://github.com/desec-io/desec-
 
stack/blob/41ee90eecb4f54d141956b33066ae9ef69442120/api/desecapi/migrations/0031_alter_user_email.py#L24

 As a result, it's not possible to initialize the database when running on
 Django 5.1.

 So, I don't think this is merely a "don't do this, it's not supported"
 case; it is in fact a regression from 5.0 to 5.1.

 How do you advise to proceed, both with this bug generally, and with our
 Django upgrade in particular? Thanks!
-- 
Ticket URL: <https://code.djangoproject.com/ticket/34898#comment:10>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070191701df6a6-f4cab768-92ae-471f-8564-0dab30980ddf-000000%40eu-central-1.amazonses.com.

Reply via email to