Support 'pyformat' style parameters in raw queries, Refs #10070

Add support for Oracle, fix an issue with the repr of RawQuerySet,
add tests and documentations. Also added a 'supports_paramstyle_pyformat'
database feature, True by default, False for SQLite.

Thanks Donald Stufft for review of documentation.

3 files changed, 34 insertions, 5 deletions

diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index a648ac1709..4e5f136e2e 100644
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -623,6 +623,14 @@ If you're getting this error, you can solve it by:
 SQLite does not support the ``SELECT ... FOR UPDATE`` syntax. Calling it will
 have no effect.
 
+"pyformat" parameter style in raw queries not supported
+-------------------------------------------------------
+
+For most backends, raw queries (``Manager.raw()`` or ``cursor.execute()``)
+can use the "pyformat" parameter style, where placeholders in the query
+are given as ``'%(name)s'`` and the parameters are passed as a dictionary
+rather than a list. SQLite does not support this.
+
 .. _sqlite-connection-queries:
 
 Parameters not quoted in ``connection.queries``
diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index 2c1fffd8cd..1fd98e1271 100644
--- a/docs/releases/1.6.txt
+++ b/docs/releases/1.6.txt
@@ -337,6 +337,12 @@ Minor features
   default) to allow customizing the :attr:`~django.forms.Form.prefix` of the
   form.
 
+* Raw queries (``Manager.raw()`` or ``cursor.execute()``) can now use the 
+  "pyformat" parameter style, where placeholders in the query are given as 
+  ``'%(name)s'`` and the parameters are passed as a dictionary rather than
+  a list (except on SQLite). This has long been possible (but not officially
+  supported) on MySQL and PostgreSQL, and is now also available on Oracle.
+
 Backwards incompatible changes in 1.6
 =====================================
 
diff --git a/docs/topics/db/sql.txt b/docs/topics/db/sql.txt
index 2ec31a4988..7437d51d28 100644
--- a/docs/topics/db/sql.txt
+++ b/docs/topics/db/sql.txt
@@ -166,9 +166,17 @@ argument to ``raw()``::
     >>> lname = 'Doe'
     >>> Person.objects.raw('SELECT * FROM myapp_person WHERE last_name = %s', [lname])
 
-``params`` is a list of parameters. You'll use ``%s`` placeholders in the
-query string (regardless of your database engine); they'll be replaced with
-parameters from the ``params`` list.
+``params`` is a list or dictionary of parameters. You'll use ``%s``
+placeholders in the query string for a list, or ``%(key)s``
+placeholders for a dictionary (where ``key`` is replaced by a
+dictionary key, of course), regardless of your database engine.  Such
+placeholders will be replaced with parameters from the ``params``
+argument.
+
+.. note:: Dictionary params not supported with SQLite
+
+   Dictionary params are not supported with the SQLite backend; with
+   this backend, you must pass parameters as a list.
 
 .. warning::
 
@@ -181,14 +189,21 @@ parameters from the ``params`` list.
 
     **Don't.**
 
-    Using the ``params`` list completely protects you from `SQL injection
+    Using the ``params`` argument completely protects you from `SQL injection
     attacks`__, a common exploit where attackers inject arbitrary SQL into
     your database. If you use string interpolation, sooner or later you'll
     fall victim to SQL injection. As long as you remember to always use the
-    ``params`` list you'll be protected.
+    ``params`` argument you'll be protected.
 
 __ http://en.wikipedia.org/wiki/SQL_injection
 
+.. versionchanged:: 1.6
+
+    In Django 1.5 and earlier, you could pass parameters as dictionaries
+    when using PostgreSQL or MySQL, although this wasn't documented. Now
+    you can also do this whem using Oracle, and it is officially supported.
+
+
 .. _executing-custom-sql:
 
 Executing custom SQL directly