From: Mike Bayer Date: Sat, 23 Aug 2014 19:21:54 +0000 (-0400) Subject: Merge branch 'pr129' X-Git-Tag: rel_1_0_0b1~205^2~49 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=b1aa0edf81680fac020bedb82ea8f8a7e8443f4b;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git Merge branch 'pr129' Conflicts: doc/build/changelog/changelog_10.rst --- b1aa0edf81680fac020bedb82ea8f8a7e8443f4b diff --cc doc/build/changelog/changelog_10.rst index 3da2c63c2a,4e75181dac..ace9569602 --- a/doc/build/changelog/changelog_10.rst +++ b/doc/build/changelog/changelog_10.rst @@@ -16,41 -16,19 +16,54 @@@ .. changelog:: :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 + + Fixed bug where attribute "set" events or columns with + ``@validates`` would have events triggered within the flush process, + when those columns were the targets of a "fetch and populate" + operation, such as an autoincremented primary key, a Python side + default, or a server-side default "eagerly" fetched via RETURNING. + + .. change:: + :tags: feature, postgresql + :tickets: 2051 + + Added support for PG table options TABLESPACE, ON COMMIT, + WITH(OUT) OIDS, and INHERITS, when rendering DDL via + the :class:`.Table` construct. Pull request courtesy + malikdiarra. + + .. seealso:: + + :ref:`postgresql_table_options` + .. change:: :tags: bug, orm, py3k