Fixed #14733: no longer "validate" .raw() queries.

Turns out that a lot more than just SELECT can return data, and this list is
very hard to define up front in a cross-database manner. So let's just assume
that anyone using raw() is at least halfway competant and can deal with
the error messages if they don't use a data-returning query.

Thanks to Christophe Pettus for the patch.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@15803 bcc190cf-cafb-0310-a4f2-bffc1f526a37

1 files changed, 10 insertions, 3 deletions

diff --git a/docs/topics/db/sql.txt b/docs/topics/db/sql.txt
index 6be59c5d5a..e5f6c21a53 100644
--- a/docs/topics/db/sql.txt
+++ b/docs/topics/db/sql.txt
@@ -42,6 +42,10 @@ You could then execute custom SQL like so::
     John Smith
     Jane Jones
 
+Of course, this example isn't very exciting -- it's exactly the same as
+running ``Person.objects.all()``. However, ``raw()`` has a bunch of other
+options that make it very powerful.
+
 .. admonition:: Model table names
 
     Where'd the name of the ``Person`` table come from in that example?
@@ -56,9 +60,12 @@ You could then execute custom SQL like so::
     :attr:`~Options.db_table` option, which also lets you manually set the
     database table name.
 
-Of course, this example isn't very exciting -- it's exactly the same as
-running ``Person.objects.all()``. However, ``raw()`` has a bunch of other
-options that make it very powerful.
+.. warning::
+
+    No checking is done on the SQL statement that is passed in to ``.raw()``.
+    Django expects that the statement will return a set of rows from the
+    database, but does nothing to enforce that. If the query does not
+    return rows, a (possibly cryptic) error will result.
 
 Mapping query fields to model fields
 ------------------------------------