Opened 7 years ago

Closed 7 years ago

#23541 closed Uncategorized (duplicate)

RunSQL Bug Django 1.7

Reported by: Aryeh Hillman Owned by: nobody
Component: Migrations Version: 1.7
Severity: Normal Keywords: migrations runsql postgresql
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Aryeh Hillman)

Django migrations are wonderful, but I believe I have found a bug. The essence of what I am trying to do here: rename all tables starting with the name "hello" (i.e. hello_1, hello2_, hello_3, ...) to start with the name "goodbye (goodbye_1, goodbye_2, goodbye_3, ...), which could be very helpful when renaming an application.

Here's how to reproduce (there is probably a more minimal case):

  1. Install this function at a shell for PostgreSQL (very handy for
CREATE FUNCTION exec(text) returns text language plpgsql volatile
  AS $f$
      EXECUTE $1;
      RETURN $1;


  1. Write a RunSQL operation to help rename some tables
class Migration(migrations.Migration):
    operations = [
            sql="""select exec(format('alter table %I rename to %I', tablename, regexp_replace(tablename, '^hello, 'goodbye'))) from pg_tables where tablename like 'hello%';"""
  1. Run the migration. I got this error:
Traceback (most recent call last):
  File "./", line 10, in <module>
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/core/management/", line 385, in execute_from_command_line
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/core/management/", line 377, in execute
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/core/management/", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/core/management/", line 338, in execute
    output = self.handle(*args, **options)
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/core/management/commands/", line 160, in handle
    executor.migrate(targets, plan, fake=options.get("fake", False))
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/db/migrations/", line 63, in migrate
    self.apply_migration(migration, fake=fake)
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/db/migrations/", line 97, in apply_migration
    migration.apply(project_state, schema_editor)
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/db/migrations/", line 107, in apply
    operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/db/migrations/operations/", line 69, in database_forwards
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/db/backends/", line 98, in execute
    cursor.execute(sql, params)
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/db/backends/", line 81, in execute
    return super(CursorDebugWrapper, self).execute(sql, params)
  File "/Users/abhillman/stable_env/lib/python2.7/site-packages/django/db/backends/", line 65, in execute
    return self.cursor.execute(sql, params)
IndexError: list index out of range

Not sure what's going on here. Could it be the custom PGSQL function?

Change History (8)

comment:1 Changed 7 years ago by Aryeh Hillman

Description: modified (diff)

comment:2 Changed 7 years ago by Aryeh Hillman

Description: modified (diff)

comment:3 Changed 7 years ago by Aryeh Hillman

Description: modified (diff)

comment:4 Changed 7 years ago by Aryeh Hillman

Description: modified (diff)

comment:5 Changed 7 years ago by Aryeh Hillman

Okay. I looked into this a bit more. I seemed to be able to resolve my issue by escaping the '%' character (i.e. convert all instances of '%%' to '%'). Inspecting the stack trace, I am not entirely clear on why this is happening. Perhaps this is the correct behavior on django's behalf. Any enlightenment on this issue would be much appreciated. In addition, I wonder if some warning message or other error message might be appropriate or helpful in this sort of situation.

comment:6 Changed 7 years ago by Claude Paroz

I think I encountered something similar while working on an unrelated issue.
Could you try applying the following diff and tell us if this changes anything for you?

diff --git a/django/db/backends/ b/django/db/backends/
index b7e285d..e2d5b54 100644
--- a/django/db/backends/
+++ b/django/db/backends/
@@ -95,7 +95,7 @@ class BaseDatabaseSchemaEditor(object):
         # Log the command we're running, then run it
         logger.debug("%s; (params %r)" % (sql, params))
         if self.collect_sql:
-            self.collected_sql.append((sql % tuple(map(self.quote_value, params))) + ";")
+            self.collected_sql.append((sql % tuple(map(self.quote_value, params or []))) + ";")
             with self.connection.cursor() as cursor:
                 cursor.execute(sql, params)
@@ -268,7 +268,7 @@ class BaseDatabaseSchemaEditor(object):
             "table": self.quote_name(model._meta.db_table),
             "definition": ", ".join(column_sqls)
-        self.execute(sql, params)
+        self.execute(sql, params or None)
         # Add any index_togethers
         for field_names in model._meta.index_together:
             fields = [model._meta.get_field_by_name(field)[0] for field in field_names]

comment:7 Changed 7 years ago by Tim Graham

I think #23426 is related.

comment:8 Changed 7 years ago by Claude Paroz

Resolution: duplicate
Status: newclosed

I'd even say it's a duplicate.

Note: See TracTickets for help on using tickets.
Back to Top