Merge branch 'pr129'

Conflicts:
	doc/build/changelog/changelog_10.rst

diff --cc doc/build/changelog/changelog_10.rst
index 3da2c63c2abfdadc8fcea829b14f97c6118379a1,4e75181dacb8bf61fef4199ad92574f77a4e373e..ace9569602aae6d2968fe97b2d7b9e10d58d73a2
--- 1/doc/build/changelog/changelog_10.rst
--- 2/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