yet the column is not the "auto increment" column, either because it has a foreign key constraint or ``autoincrement=False`` set, would attempt to fire the Sequence on INSERT for backends that don't support sequences, when presented with an INSERT missing the primary key value. This would take place on non-sequence backends like SQLite, MySQL. [ticket:2896]
of the given names would not be taken into account when generating the INSERT statement, thus producing a mismatch versus the column names in the given SELECT statement. Also noted that :meth:`.Insert.from_select` implies that Python-side insert defaults cannot be used, since the statement has no VALUES clause. [ticket:2895]
backwards compatibility. A note about backslashing escapes is added. Because the Text() construct now supports bind params better, the example given in the code raises an exception now, so that should cover us. The exception itself has been enhanced to include the key name of the bound param. We're backporting this to 0.8 but 0.8 doesn't have the text->bind behavior that raises. Conflicts: lib/sqlalchemy/sql/schema.py
mssql to ensure that any literal SQL expression values are rendered directly as literals, instead of as bound parameters, within a CREATE INDEX statement. [ticket:2742] - don't need expression_as_ddl(); literal_binds and include_table take care of this functionality. Conflicts: lib/sqlalchemy/sql/util.py
with CreateColumn rules
compilation rule which allows skipping of columns, by producing a rule that returns ``None``. Also in 0.8.3. Conflicts: doc/build/changelog/changelog_09.rst lib/sqlalchemy/sql/ddl.py
not be properly quoted if it was referred to in multiple FROM clauses. Also in 0.8.3, 0.7.11. [ticket:2801] Conflicts: doc/build/changelog/changelog_09.rst
used only as an ``alias()`` construct, it would not render using the WITH keyword. Also in 0.7.11. [ticket:2783]
form of a some expressions when referring to the ``.c`` collection on a ``select()`` construct, but the ``str()`` form isn't available since the element relies on dialect-specific compilation constructs, notably the ``__getitem__()`` operator as used with a Postgresql ``ARRAY`` element. The fix also adds a new exception class :class:`.UnsupportedCompilationError` which is raised in those cases where a compiler is asked to compile something it doesn't know how to. [ticket:2780]