Allow database connection initialization commands

cc'ing me

See also #3460.

Wrote a patch to fix this, with documentation. It should be fairly straighforward:

Added a CONNECTION_INIT_SQL setting, which is a tuple of strings to be executed on connection initialization.

For example,

CONNECTION_INIT_SQL = (
    'SET search_path TO django_application_schema',
)

would accomplish the same thing as ticket:1051

Ran test suite and there were no regressions, but tests for this new feature are needed.

Patch to add CONNECTION_INIT_SQL setting and use it on connection initialization.

Looking at this, I *REALLY* don't like having SQL in the settings file. So I think that a connection-created signal is the right way to do this, not a setting.

I have added a new patch which uses signals instead of a setting. I think you're right, too, that the signal method is better. It allows for more flexibility while not cluttering up the settings file. The only reason that I originally implemented the settings file originally was due to concerns about performance.

One thing: I wasn't sure where to put the new signal. It doesn't seem to fit where any of the other signals are defined, so I created django.db.backends.signals with this one signal in it.

Changed the implementation method to emit a signal instead of execute a tuple from the settings.

For anyone looking for a quick and dirty solution you ca define your table like this: db_table = '"django"."company"'. This will fool the quote function to think that your table is properly quoted. This also means that you have to specify the schema for each table manually.

cc'ing me too (hello !)

Updated patch to apply against trunk as of r9477.

I just updated this patch to work with the current trunk, since it hadn't been touched for a year and had gotten rather stale. I also fixed some bugs that were causing connection_created signals to be sent on every cursor-creation for some back ends, rather than only when a new database connection has really been made.

Unfortunately, fixing that bug broke the test for sqlite3, since in-memory sqlite3 databases (of the sort used by the tests) are never actually closed, and thus cannot be reopened by the tests. So I've had to disable the test altogether for sqlite3, unless someone can come up with a definitely-safe way to open a second temporary database somehow without clobbering the old one. Seems like more trouble than it's worth.

It occurs to me that a separate cursor_created signal might actually be useful, especially if it were passed a reference to the new cursor, but, well, one thing at a time.

cc'ing

(In [10182]) Fixed #6064 -- Added the connection_created signal for when a database connection is created.