One can use this to emit statements, which can not be
executed within a transaction (e. g. CREATE DATABASE):
from sqlalchemy import create_engine
eng = create_engine('postgresql://test:test@localhost/test')
conn = eng.connect().execution_options(isolation_level='AUTOCOMMIT')
conn.execute('CREATE DATABASE test2;')
Fixes issue #2072.
Currently, one can specify the prefix length for an index
column using 'mysql_length' keyword argument when creating
an Index instance. But in case of composite indexes the
prefix length value is applied only to the last column.
Extend the existing API in way so that 'mysql_length' argument
value can be either:
- an integer specifying the same prefix length value
for each column of an index
- a (column_name --> integer value) mapping specifying
the prefix length value for each column of an index
separately
Fixes issue #2704.
a CAST call that was added in 0.8.1 to help with driver issues,
which apparently is not compatible on 2000.
The CAST remains in place for SQL Server 2005 and greater.
[ticket:2747]
:class:`.ForeignKeyConstraint` will not render the ``DEFERRABLE`` keyword
on the MySQL dialect. For a long time we left this in place because
a non-deferrable foreign key would act very differently than a deferrable
one, but some environments just disable FKs on MySQL, so we'll be less
opinionated here. [ticket:2721]
input types of sets, generators, etc. but only when a dimension
is specified for the ARRAY; otherwise, the dialect
needs to peek inside of "arr[0]" to guess how many
dimensions are in use. If this occurs with a non
list/tuple type, the error message is now informative
and directs to specify a dimension for the ARRAY.
[ticket:2681]
- Part of a longer series of fixes needed for pyodbc+
mssql, a CAST to NVARCHAR(max) has been added to the bound
parameter for the table name and schema name in all information schema
queries to avoid the issue of comparing NVARCHAR to NTEXT,
which seems to be rejected by the ODBC driver in some cases,
such as FreeTDS (0.91 only?) plus unicode bound parameters being passed.
The issue seems to be specific to the SQL Server information
schema tables and the workaround is harmless for those cases
where the problem doesn't exist in the first place.
[ticket:2355]
function syntax, renders as "SUBSTRING(x FROM y FOR z)"
when regular ``func.substring()`` is used.
Also in 0.7.11. Courtesy Gunnlaugur Por Briem.
[ticket:2676]
Roman Podolyaka