Alright, that makes sense.  So, my thought is, if we can't change the
call to connection.cursor() on each instantiation, we're going to need
some sort of static variable store that can get updated at runtime (or
some global).  I know that settings is right out for anything that
changes at runtime, is there a Django-friendly way of storing a variable
of this nature?  If we can store this variable in some more non-code
changing way, the rest of the patch should be fine, right?  Here's my
two thoughts for hopefully Django-friendly approaches:

First, Brian Ferring's base class could have a static or class variable
easily enough, but I'd like this landing not to depend on that refactor,
since that could be a while coming.

Second, we could add a class level variable to each DatabaseWrapper,
since the handle to those seem to be instantiated only once at runtime
(at least, my short testing with just the Django built-in webserver
seemed to do so, I only assume that for Apache it's once per thread).
That would be an easy enough variable to update from pretty much
anywhere in the app:

     connection.playback_only = True

*should* be all we would need, anywhere in the app.  If need be, we can
add a helper to disguise this call, but every connection.cursor()
creation at that would just need to check for self.playback_only to get
the same effect as in the previously sent patch.

Thoughts?
George