diff options
| author | Mike Bayer <mike_mp@zzzcomputing.com> | 2014-08-20 20:14:20 -0400 |
|---|---|---|
| committer | Mike Bayer <mike_mp@zzzcomputing.com> | 2014-08-20 20:14:20 -0400 |
| commit | 71ca494f518658676b532afaf84a4cc93025dbbb (patch) | |
| tree | 7de7ba2791382d35a051b3f15474945f14b2890e /doc | |
| parent | 89ff6df7dcdfa144efbd4d7c2031c0643a266351 (diff) | |
| download | sqlalchemy-71ca494f518658676b532afaf84a4cc93025dbbb.tar.gz | |
- 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
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/build/changelog/changelog_10.rst | 25 |
1 files changed, 25 insertions, 0 deletions
diff --git a/doc/build/changelog/changelog_10.rst b/doc/build/changelog/changelog_10.rst index 1cbbec3b3..3da2c63c2 100644 --- a/doc/build/changelog/changelog_10.rst +++ b/doc/build/changelog/changelog_10.rst @@ -17,6 +17,31 @@ :version: 1.0.0 .. change:: + :tags: bug, sql + :tickets: 3169 + + 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. + + .. change:: :tags: bug, orm :tickets: 3167 |