#31653: PostgreSQL add constraints via NOT VALID / VALIDATE CONSTRAINT -------------------------------------+------------------------------------- Reporter: Adam (Chainz) | Owner: nobody Johnson | Type: | Status: new Cleanup/optimization | Component: Migrations | Version: master Severity: Normal | Resolution: Keywords: | Triage Stage: | Unreviewed Has patch: 0 | Needs documentation: 0 Needs tests: 0 | Patch needs improvement: 0 Easy pickings: 0 | UI/UX: 0 -------------------------------------+-------------------------------------
Comment (by Adam (Chainz) Johnson): > My interpretation is that in order for other transactions to see that the constraint was added in a READ COMMITTED scenario the ADD CONSTRAINT NOT VALID must be committed first; performing a ADD CONSTRAINT NOT VALID and VALIDATE CONSTRAINT in the same transaction should result in the same operations as ADD CONSTRAINT otherwise PostgreSQL would always do it by default? Yes... the one time I've used `NOT VALID` was actually in an `atomic = False` migration so I didn't test it with atomic. I was probably too zealous reading the PostgreSQL docs which don't mention transactions. I think custom `django.contrib.postgres` operations would be the way. They can document to use non-atomic migrations. Rather than `AddConstraint(..., validate=False)` I'd suggest `AddConstraintNotValid(...)` as a subclass of `AddConstraint`, and `ValidateConstraint`. -- Ticket URL: <https://code.djangoproject.com/ticket/31653#comment:5> 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 django-updates+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/068.a7fd0ea55642db03fc9eebbb9c03e0da%40djangoproject.com.