#35625: ProgrammingError with Postgres backend when setting db_default and
constraint using the LIKE operator
-------------------------------------+-------------------------------------
     Reporter:  Julien Chaumont      |                    Owner:  Simon
                                     |  Charette
         Type:  Bug                  |                   Status:  assigned
    Component:  Migrations           |                  Version:  5.0
     Severity:  Normal               |               Resolution:
     Keywords:  db_default,          |             Triage Stage:  Accepted
  postgres                           |
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):

 * owner:  (none) => Simon Charette
 * stage:  Unreviewed => Accepted
 * status:  new => assigned

Comment:

 Managed to reproduce. The issue is in the same vein as #35336 and the long
 tail of problems related to improper escaping handling in the schema
 editor (#30408, #34553, #32369).

 The big design problem here is that the
 `Constraint.(constraint|create|delete)_sql` interface returns `sql: str`
 instead of `(sql: str, params: tuple)` to the schema editor which has no
 other choice not to use backend bindings (passing `(sql, None)` to
 `cursor.execute`) but it decides to do so when `requires_literal_defaults
 = False` (PostgresSQL, MySQL) for `DEFAULT`. In other words, unless we
 change `Constraint` and `Index` to return un-parametrized SQL we cannot
 use parametrized SQL when performing any operation that involve them.

 I think we should mark this one as a release blocker because `db_default`
 was added in 5.0 and the latter still receives patches for bugs in new
 features until 5.1 is released?

 I'll try to work on a non-invasive patch that can be backported and likely
 create another issue to discuss switching the whole DDL generation
 machinery to provide `(sql: str, params: tuple)` and let the schema editor
 decide how it wants to deal with parametrization (use it on Postgres +
 MySQL) and rely on `quote_value` otherwise through a single
 `supports_parametrized_ddl` feature flag.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/35625#comment:1>
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/01070190dc10e78e-8c248fae-dff8-4bb2-acdc-b8eed33c2678-000000%40eu-central-1.amazonses.com.

Reply via email to