]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commit
- The INSERT...FROM SELECT construct now implies ``inline=True``
authorMike Bayer <mike_mp@zzzcomputing.com>
Thu, 21 Aug 2014 00:14:20 +0000 (20:14 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Thu, 21 Aug 2014 00:14:20 +0000 (20:14 -0400)
commit71ca494f518658676b532afaf84a4cc93025dbbb
tree7de7ba2791382d35a051b3f15474945f14b2890e
parent89ff6df7dcdfa144efbd4d7c2031c0643a266351
- The INSERT...FROM SELECT construct now implies ``inline=True``
on :class:`.Insert`.  This helps to fix a bug where an
INSERT...FROM SELECT construct would inadvertently be compiled
as "implicit returning" on supporting backends, which would
cause breakage in the case of an INSERT that inserts zero rows
(as implicit returning expects a row), as well as arbitrary
return data in the case of an INSERT that inserts multiple
rows (e.g. only the first row of many).
A similar change is also applied to an INSERT..VALUES
with multiple parameter sets; implicit RETURNING will no longer emit
for this statement either.  As both of these constructs deal
with varible numbers of rows, the
:attr:`.ResultProxy.inserted_primary_key` accessor does not
apply.   Previously, there was a documentation note that one
may prefer ``inline=True`` with INSERT..FROM SELECT as some databases
don't support returning and therefore can't do "implicit" returning,
but there's no reason an INSERT...FROM SELECT needs implicit returning
in any case.   Regular explicit :meth:`.Insert.returning` should
be used to return variable numbers of result rows if inserted
data is needed.
fixes #3169
doc/build/changelog/changelog_10.rst
lib/sqlalchemy/sql/compiler.py
lib/sqlalchemy/sql/dml.py
test/sql/test_insert.py
test/sql/test_query.py