commit 1b774808c926665047bf353222ecd191679a95d1

Author: Lele Gaifax <lele@metapensiero.it> Date: Tue Dec 25 12:35:41 2018 +0100 Consistently use "PostgreSQL", fixing also a few doc glitches commit 0e382aaee4427193926f0dc10ad29056bc12c85e Author: Lele Gaifax <lele@metapensiero.it> Date: Tue Dec 25 12:08:49 2018 +0100 Remove duplicated words Change-Id: Iaa586b9412f46a50fe6ff3bbb92e07d6cb1905c8
2018-12-30 21:16:52 -05:00
parent cfc49b4571
commit c0f9708fde
25 changed files with 82 additions and 82 deletions
@@ -23,7 +23,7 @@ Python 2.7 using an in-memory SQLite database::

 The tox runner contains a series of target combinations that can run
 against various combinations of databases.  The test suite can be
-run against SQLite with "backend" tests also running against a Postgresql
+run against SQLite with "backend" tests also running against a PostgreSQL
 database::

    tox -e py36-sqlite-postgresql
@@ -64,13 +64,13 @@ quickly allow for custom database connections.  Example::

 Above will run the tests in the test/sql/test_query.py file (a pretty good
 file for basic "does this database work at all?" to start with) against a
-running Postgresql database at the given URL.
+running PostgreSQL database at the given URL.

 The py.test frontend can also run tests against multiple kinds of databases
 at once - a large subset of tests are marked as "backend" tests, which will
 be run against each available backend, and additionally lots of tests are targeted
 at specific backends only, which only run if a matching backend is made available.
-For example, to run the test suite against both Postgresql and MySQL at the same time::
+For example, to run the test suite against both PostgreSQL and MySQL at the same time::

    py.test -n4 --db postgresql --db mysql

@@ -217,7 +217,7 @@
        ``_reset_exported()`` would corrupt the state of the object.  This
        method is intended for selectable objects and is called by the ORM
        in some cases; an erroneous mapper configuration would could lead the
-        ORM to call this on on a :class:`.Table` object.
+        ORM to call this on a :class:`.Table` object.

    .. change::
        :tags: bug, ext
@@ -703,7 +703,7 @@
        construct, when the target :class:`.Table` has Python-side defaults.
        The :class:`.Select` construct would compile standalone with the
        erroneous column present subsequent to compilation of the
-        :class:`.Insert`, and the the :class:`.Insert` statement itself would
+        :class:`.Insert`, and the :class:`.Insert` statement itself would
        fail on a second compile attempt due to duplicate bound parameters.

    .. change::
@@ -41,7 +41,7 @@
        :tickets: 4208
        :versions: 1.2.5

-        Fixed bug in Postgresql COLLATE / ARRAY adjustment first introduced
+        Fixed bug in PostgreSQL COLLATE / ARRAY adjustment first introduced
        in :ticket:`4006` where new behaviors in Python 3.7 regular expressions
        caused the fix to fail.

@@ -130,7 +130,7 @@
        :versions: 1.2.3

        Added "TRUNCATE" to the list of keywords accepted by the
-        Postgresql dialect as an "autocommit"-triggering keyword.
+        PostgreSQL dialect as an "autocommit"-triggering keyword.
        Pull request courtesy Jacob Hayes.

    .. change::
@@ -251,7 +251,7 @@
        :versions: 1.2.0b3

        Fixed bug in :obj:`.array_agg` function where passing an argument
-        that is already of type :class:`.ARRAY`, such as a Postgresql
+        that is already of type :class:`.ARRAY`, such as a PostgreSQL
        :obj:`.postgresql.array` construct, would produce a ``ValueError``, due
        to the function attempting to nest the arrays.

@@ -270,7 +270,7 @@
        :tickets: 4074
        :versions: 1.2.0b3

-        Fixed bug in Postgresql :meth:`.postgresql.dml.Insert.on_conflict_do_update`
+        Fixed bug in PostgreSQL :meth:`.postgresql.dml.Insert.on_conflict_do_update`
        which would prevent the insert statement from being used as a CTE,
        e.g. via :meth:`.Insert.cte`, within another statement.

@@ -467,12 +467,12 @@
        :tickets: 4005
        :versions: 1.2.0b1

-        Continuing with the fix that correctly handles Postgresql
+        Continuing with the fix that correctly handles PostgreSQL
        version string "10devel" released in 1.1.8, an additional regexp
        bump to handle version strings of the form "10beta1".   While
-        Postgresql now offers better ways to get this information, we
+        PostgreSQL now offers better ways to get this information, we
        are sticking w/ the regexp at least through 1.1.x for the least
-        amount of risk to compatibility w/ older or alternate Postgresql
+        amount of risk to compatibility w/ older or alternate PostgreSQL
        databases.

    .. change:: 4006
@@ -635,7 +635,7 @@

        Changed the mechanics of :class:`.ResultProxy` to unconditionally
        delay the "autoclose" step until the :class:`.Connection` is done
-        with the object; in the case where Postgresql ON CONFLICT with
+        with the object; in the case where PostgreSQL ON CONFLICT with
        RETURNING returns no rows, autoclose was occurring in this previously
        non-existent use case, causing the usual autocommit behavior that
        occurs unconditionally upon INSERT/UPDATE/DELETE to fail.
@@ -671,7 +671,7 @@
        :tags: bug, postgresql
        :versions: 1.2.0b1

-        Added support for parsing the Postgresql version string for
+        Added support for parsing the PostgreSQL version string for
        a development version like "PostgreSQL 10devel".  Pull request
        courtesy Sean McCully.

@@ -784,7 +784,7 @@
        :tickets: 3804

        Added regular expressions for the "IMPORT FOREIGN SCHEMA",
-        "REFRESH MATERIALIZED VIEW" Postgresql statements so that they
+        "REFRESH MATERIALIZED VIEW" PostgreSQL statements so that they
        autocommit when invoked via a connection or engine without
        an explicit transaction.  Pull requests courtesy Frazer McLean
        and Paweł Stiasny.
@@ -838,7 +838,7 @@
        :tags: bug, postgresql
        :tickets: 3900

-        Fixed bug in Postgresql :class:`.ExcludeConstraint` where the
+        Fixed bug in PostgreSQL :class:`.ExcludeConstraint` where the
        "whereclause" and "using" parameters would not be copied during an
        operation like :meth:`.Table.tometadata`.

@@ -1129,7 +1129,7 @@
        pymysql dialects.   This feature is available via the
        :paramref:`.Connection.execution_options.stream_results` flag as well
        as the ``server_side_cursors=True`` dialect argument in the
-        same way that it has been for psycopg2 on Postgresql.  Pull request
+        same way that it has been for psycopg2 on PostgreSQL.  Pull request
        courtesy Roman Podoliaka.

    .. change::
@@ -1175,7 +1175,7 @@
        :tags: bug, postgresql
        :tickets: 3835

-        Postgresql table reflection will ensure that the
+        PostgreSQL table reflection will ensure that the
        :paramref:`.Column.autoincrement` flag is set to False when reflecting
        a primary key column that is not of an :class:`.Integer` datatype,
        even if the default is related to an integer-generating sequence.
@@ -834,7 +834,7 @@
        :tags: bug, postgresql
        :tickets: 4229

-        Fixed bug where the special "not equals" operator for the Postgresql
+        Fixed bug where the special "not equals" operator for the PostgreSQL
        "range" datatypes such as DATERANGE would fail to render "IS NOT NULL" when
        compared to the Python ``None`` value.

@@ -871,7 +871,7 @@

        Fixed issue where the compilation of an INSERT statement with the
        "literal_binds" option that also uses an explicit sequence and "inline"
-        generation, as on Postgresql and Oracle, would fail to accommodate the
+        generation, as on PostgreSQL and Oracle, would fail to accommodate the
        extra keyword argument within the sequence processing routine.

    .. change::
@@ -901,7 +901,7 @@
    .. change::
        :tags: feature, postgresql

-        Added support for "PARTITION BY" in Postgresql table definitions,
+        Added support for "PARTITION BY" in PostgreSQL table definitions,
        using "postgresql_partition_by".  Pull request courtesy
        Vsevolod Solovyov.

@@ -1325,7 +1325,7 @@
        :tags: enhancement, sql
        :tickets: 959

-        Implemented "DELETE..FROM" syntax for Postgresql, MySQL, MS SQL Server
+        Implemented "DELETE..FROM" syntax for PostgreSQL, MySQL, MS SQL Server
        (as well as within the unsupported Sybase dialect) in a manner similar
        to how "UPDATE..FROM" works.  A DELETE statement that refers to more than
        one table will switch into "multi-table" mode and render the appropriate
@@ -1859,7 +1859,7 @@
        :class:`.Boolean` types, which now extend a common mixin
        :class:`.Emulated` that indicates a type that provides Python-side
        emulation of a DB native type, switching out to the DB native type when a
-        supporting backend is in use.   The Postgresql :class:`.INTERVAL` type
+        supporting backend is in use.   The PostgreSQL :class:`.INTERVAL` type
        when used directly will now include the correct type coercion rules for
        SQL expressions that also take effect for :class:`.sqltypes.Interval`
        (such as adding a date to an interval yields a datetime).
@@ -2150,7 +2150,7 @@
        each other will produce parentheses between them.   This suits the
        stated operator precedence of databases like Oracle, MySQL and others
        which place all of these operators as equal precedence, as well as
-        Postgresql as of 9.5 which has also flattened its operator precendence.
+        PostgreSQL as of 9.5 which has also flattened its operator precendence.

        .. seealso::

@@ -2330,7 +2330,7 @@
        signs mostly associated with the :obj:`.literal_column` construct
        as well as operators like :meth:`.ColumnOperators.contains` now
        occurs based on the stated paramstyle of the DBAPI in use; for
-        percent-sensitive paramstyles as are common with the Postgresql
+        percent-sensitive paramstyles as are common with the PostgreSQL
        and MySQL drivers the doubling will occur, for others like that
        of SQLite it will not.   This allows more database-agnostic use
        of the :obj:`.literal_column` construct to be possible.
@@ -2344,7 +2344,7 @@
        :tickets: 3959

        Added support for all possible "fields" identifiers when reflecting the
-        Postgresql ``INTERVAL`` datatype, e.g. "YEAR", "MONTH", "DAY TO
+        PostgreSQL ``INTERVAL`` datatype, e.g. "YEAR", "MONTH", "DAY TO
        MINUTE", etc..   In addition, the :class:`.postgresql.INTERVAL`
        datatype itself now includes a new parameter
        :paramref:`.postgresql.INTERVAL.fields` where these qualifiers can be
@@ -2482,7 +2482,7 @@
        as part of DDL on table creation, either inline or via an appropriate
        ALTER statement, and are also reflected back within table reflection,
        as well as via the :class:`.Inspector`.   Supported backends currently
-        include MySQL, Postgresql, and Oracle.  Many thanks to Frazer McLean
+        include MySQL, PostgreSQL, and Oracle.  Many thanks to Frazer McLean
        for a large amount of effort on this.

        .. seealso::
@@ -2518,7 +2518,7 @@
        into a parenthesized expression.   Using :class:`.Alias` in this way
        is not yet a fully supported API, however it applies to some end-user
        recipes and may have a more prominent role in support of some
-        future Postgresql features.
+        future PostgreSQL features.

    .. change:: 3366
        :tags: bug, orm
@@ -175,7 +175,7 @@
        means the query renders with two FOR UPDATE clauses; note that on some
        backends such as Oracle, FOR UPDATE clauses on subqueries are silently
        ignored since they are unnecessary.  Additionally, in the case of the "OF"
-        clause used primarily with Postgresql, the FOR UPDATE is rendered only on
+        clause used primarily with PostgreSQL, the FOR UPDATE is rendered only on
        the inner subquery when this is used so that the selectable can be targeted
        to the table within the SELECT statement.

@@ -237,7 +237,7 @@
       :tags: feature, postgresql
       :tickets: 4237

-       Added rudimental support for reflection of Postgresql
+       Added rudimental support for reflection of PostgreSQL
       partitioned tables, e.g. that relkind='p' is added to reflection
       queries that return table information.

@@ -1652,9 +1652,9 @@ retained as None/NULL.
   integer values, such as strings, also changed in behavior such that the
   string value ``"0"`` would be interpreted as "true", but only on backends
   that don't have a native boolean datatype - on "native boolean" backends
-   like Postgresql, the string value ``"0"`` is passed directly to the driver
+   like PostgreSQL, the string value ``"0"`` is passed directly to the driver
   and is interpreted as "false".  This is an inconsistency that did not occur
-   with the previous implementation.It should be noted that passing strings or
+   with the previous implementation. It should be noted that passing strings or
   any other value outside of ``None``, ``True``, ``False``, ``1``, ``0`` to
   the :class:`.Boolean` datatype is **not supported** and version 1.2 will
   raise an error for this scenario (or possibly just emit a warning, TBD).
@@ -2220,7 +2220,7 @@ expressions to :meth:`.Query.distinct`, the above "column adding" logic
 is disabled entirely.

 When the query is being bundled into a subquery for the purposes of
-joined eager loading, the "augment column list" rules are are necessarily
+joined eager loading, the "augment column list" rules are necessarily
 more aggressive so that the ORDER BY can still be satisfied, so this case
 remains unchanged.

@@ -140,7 +140,7 @@ The above SELECT statement includes these advantages:
 * Because the query only fetches for a given list of primary key identifiers,
  "selectin" loading is potentially compatible with :meth:`.Query.yield_per` to
  operate on chunks of a SELECT result at a time, provided that the
-  database driver allows for multiple, simultaneous cursors (SQlite, Postgresql;
+  database driver allows for multiple, simultaneous cursors (SQlite, PostgreSQL;
  **not** MySQL drivers or SQL Server ODBC drivers).   Neither joined eager
  loading nor subquery eager loading are compatible with :meth:`.Query.yield_per`.

@@ -151,7 +151,7 @@ will have more additional "SELECT IN" queries following.  Also, support
 for composite primary keys depends on the database's ability to use
 tuples with IN, e.g.
 ``(table.column_one, table_column_two) IN ((?, ?), (?, ?) (?, ?))``.
-Currently, Postgresql and MySQL are known to be compatible with this syntax,
+Currently, PostgreSQL and MySQL are known to be compatible with this syntax,
 SQLite is not.

 .. seealso::
@@ -779,7 +779,7 @@ follows::
    SELECT NULL IN (SELECT 1 WHERE 1 != 1)

 With the above test, we see that the databases themselves can't agree on
-the answer.  Postgresql, considered by most to be the most "correct" database,
+the answer.  PostgreSQL, considered by most to be the most "correct" database,
 returns False; because even though "NULL" represents "unknown", the "empty set"
 means nothing is present, including all unknown values.  On the
 other hand, MySQL and MariaDB return NULL for the above expression, defaulting
@@ -794,7 +794,7 @@ With the compilation-time behavior, the dialect itself can be instructed
 to invoke either approach, that is, the "static" ``1 != 1`` comparison or the
 "dynamic" ``expr != expr`` comparison.   The default has been **changed**
 to be the "static" comparison, since this agrees with the behavior that
-Postgresql would have in any case and this is also what the vast majority
+PostgreSQL would have in any case and this is also what the vast majority
 of users prefer.   This will **change the result** of a query that is comparing
 a null expression to the empty set, particularly one that is querying
 for the negation ``where(~null_expr.in_([]))``, since this now evaluates to true
@@ -873,7 +873,7 @@ the above table is autoloaded or inspected with :meth:`.Inspector.get_columns`,
 the comments are included.   The table comment is also available independently
 using the :meth:`.Inspector.get_table_comment` method.

-Current backend support includes MySQL, Postgresql, and Oracle.
+Current backend support includes MySQL, PostgreSQL, and Oracle.

 :ticket:`1546`

@@ -884,7 +884,7 @@ Multiple-table criteria support for DELETE

 The :class:`.Delete` construct now supports multiple-table criteria,
 implemented for those backends which support it, currently these are
-Postgresql, MySQL and Microsoft SQL Server (support is also added to the
+PostgreSQL, MySQL and Microsoft SQL Server (support is also added to the
 currently non-working Sybase dialect).   The feature works in the same
 was as that of multiple-table criteria for UPDATE, first introduced in
 the 0.7 and 0.8 series.
@@ -896,7 +896,7 @@ Given a statement as::
            where(addresses.c.email_address.startswith('ed%'))
    conn.execute(stmt)

-The resulting SQL from the above statement on a Postgresql backend
+The resulting SQL from the above statement on a PostgreSQL backend
 would render as::

    DELETE FROM users USING addresses
@@ -919,8 +919,8 @@ The "autoescape" parameter is added to :meth:`.ColumnOperators.startswith`,
 This parameter when set to ``True`` will automatically escape all occurrences
 of ``%``, ``_`` with an escape character, which defaults to a forwards slash ``/``;
 occurrences of the escape character itself are also escaped.  The forwards slash
-is used to avoid conflicts with settings like Postgresql's
-``standard_confirming_strings``, whose default value changed as of Postgresql
+is used to avoid conflicts with settings like PostgreSQL's
+``standard_confirming_strings``, whose default value changed as of PostgreSQL
 9.1, and MySQL's ``NO_BACKSLASH_ESCAPES`` settings.  The existing "escape" parameter
 can now be used to change the autoescape character, if desired.

@@ -1452,7 +1452,7 @@ same as the left-hand expression::
    DateTime()

 As most user-defined operators tend to be "comparison" operators, often
-one of the many special operators defined by Postgresql, the
+one of the many special operators defined by PostgreSQL, the
 :paramref:`.Operators.op.is_comparison` flag has been repaired to follow
 its documented behavior of allowing the return type to be :class:`.Boolean`
 in all cases, including for :class:`.ARRAY` and :class:`.JSON`::
@@ -1570,7 +1570,7 @@ on by default in a future release.
 Support for fields specification in INTERVAL, including full reflection
 -----------------------------------------------------------------------

-The "fields" specifier in Postgresql's INTERVAL datatype allows specification
+The "fields" specifier in PostgreSQL's INTERVAL datatype allows specification
 of which fields of the interval to store, including such values as "YEAR",
 "MONTH", "YEAR TO MONTH", etc.   The :class:`.postgresql.INTERVAL` datatype
 now allows these values to be specified::
@@ -77,8 +77,8 @@ lazy loading uses in order to determine if related entities can be fetched
 directly from the identity map.   However, as with most querying features,
 the feature's implementation became more complex as a result of advanced
 scenarios regarding polymorphic loading.   If problems are encountered,
-users should report a bug, however the change also incldues a flag
-:paramref:`.relationship.omit_join` which can be set to False on the
+users should report a bug, however the change also includes a flag
+:paramref:`.relationship.omit_join` which can be set to ``False`` on the
 :func:`.relationship` to disable the optimization.


@@ -716,7 +716,7 @@ combined with "SELECT..FOR UPDATE", the behavior has been this::
    ) AS subq LEFT OUTER JOIN b ON subq.a_id=b.a_id FOR UPDATE

 However, MySQL due to https://bugs.mysql.com/bug.php?id=90693 does not lock
-the rows inside the subquery, unlike that of Postgresql and other databases.
+the rows inside the subquery, unlike that of PostgreSQL and other databases.
 So the above query now renders as::

    SELECT subq.a_id, subq.a_data, b_alias.id, b_alias.data FROM (
@@ -725,11 +725,11 @@ So the above query now renders as::

 On the Oracle dialect, the inner "FOR UPDATE" is not rendered as Oracle does
 not support this syntax and the dialect skips any "FOR UPDATE" that is against
-a subquery; it isn't necessary in any case since Oracle, like Postgresql,
+a subquery; it isn't necessary in any case since Oracle, like PostgreSQL,
 correctly locks all elements of the returned row.

 When using the :paramref:`.Query.with_for_update.of` modifier, typically on
-Postgresql, the outer "FOR UPDATE" is omitted, and the OF is now rendered
+PostgreSQL, the outer "FOR UPDATE" is omitted, and the OF is now rendered
 on the inside; previously, the OF target would not be converted to accommodate
 for the subquery correctly.  So
 given::
@@ -742,7 +742,7 @@ The query would now render as::
        SELECT a.id AS a_id, a.data AS a_data FROM a LIMIT 5 FOR UPDATE OF a
    ) AS subq LEFT OUTER JOIN b ON subq.a_id=b.a_id

-The above form should be helpful on Postgresql additionally since Postgresql
+The above form should be helpful on PostgreSQL additionally since PostgreSQL
 will not allow the FOR UPDATE clause to be rendered after the LEFT OUTER JOIN
 target.

@@ -948,7 +948,7 @@ Expanding IN feature now supports empty lists
 The "expanding IN" feature introduced in version 1.2 at :ref:`change_3953` now
 supports empty lists passed to the :meth:`.ColumnOperators.in_` operator.   The implementation
 for an empty list will produce an "empty set" expression that is specific to a target
-backend, such as "SELECT CAST(NULL AS INTEGER) WHERE 1!=1" for Postgresql,
+backend, such as "SELECT CAST(NULL AS INTEGER) WHERE 1!=1" for PostgreSQL,
 "SELECT 1 FROM (SELECT 1) as _empty_set WHERE 1!=1" for MySQL::

    >>> from sqlalchemy import create_engine
@@ -965,7 +965,7 @@ backend, such as "SELECT CAST(NULL AS INTEGER) WHERE 1!=1" for Postgresql,

 The feature also works for tuple-oriented IN statements, where the "empty IN"
 expression will be expanded to support the elements given inside the tuple,
-such as on Postgresql::
+such as on PostgreSQL::

    >>> from sqlalchemy import create_engine
    >>> from sqlalchemy import select, literal_column, tuple_, bindparam
@@ -1062,10 +1062,10 @@ Dialect Improvements and Changes - PostgreSQL

 .. _change_4237:

-Added basic reflection support for Postgresql paritioned tables
---------------------------------------------------------------
+Added basic reflection support for PostgreSQL partitioned tables
+----------------------------------------------------------------

-SQLAlchemy can render the "PARTITION BY" sequnce within a Postgresql
+SQLAlchemy can render the "PARTITION BY" sequence within a PostgreSQL
 CREATE TABLE statement using the flag ``postgresql_partition_by``, added in
 version 1.2.6.    However, the ``'p'`` type was not part of the reflection
 queries used until now.
@@ -14,6 +14,6 @@
   Fixed issue where multiple :class:`.postgresql.ENUM` objects referred to
   by the same :class:`.MetaData` object would fail to be created if
   multiple objects had the same name under different schema names.  The
-   internal memoization the Postgresql dialect uses to track if it has
+   internal memoization the PostgreSQL dialect uses to track if it has
   created a particular :class:`.postgresql.ENUM` in the database during
   a DDL creation sequence now takes schema name into account.
@@ -7,5 +7,5 @@
   like a regular ad-hoc function.  This to suit the case that many of
   these functions on specific backends accept arguments such as
   "fractional seconds" precision and such.  If the function is created
-   with arguments, it renders the the parenthesis and the arguments.  If
-   no arguents are present, the compiler generates the non-parenthesized form.
+   with arguments, it renders the parenthesis and the arguments.  If
+   no arguments are present, the compiler generates the non-parenthesized form.
@@ -428,7 +428,7 @@ and that options like default schema are propagated, setting the
 Associating a Sequence as the Server Side Default
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-.. note:: The following technique is known to work only with the Postgresql
+.. note:: The following technique is known to work only with the PostgreSQL
   database.  It does not work with Oracle.

 The preceding sections illustrate how to associate a :class:`.Sequence` with a
@@ -2155,7 +2155,7 @@ implicitly, by specifying multiple tables in the WHERE clause::
            where(addresses.c.email_address.startswith('ed%'))
    conn.execute(stmt)

-On a Postgresql backend, the resulting SQL from the above statement would render as::
+On a PostgreSQL backend, the resulting SQL from the above statement would render as::

    DELETE FROM users USING addresses
    WHERE users.id = addresses.id
@@ -131,7 +131,7 @@ delete

 The ``delete`` cascade indicates that when a "parent" object
 is marked for deletion, its related "child" objects should also be marked
-for deletion.   If for example we we have a relationship ``User.addresses``
+for deletion.   If for example we have a relationship ``User.addresses``
 with ``delete`` cascade configured::

    class User(Base):
@@ -475,7 +475,7 @@ the one against ``Manager`` will be:
 Note that selectin polymorphic loading has similar caveats as that of
 selectin relationship loading; for entities that make use of a composite
 primary key, the database in use must support tuples with "IN", currently
-known to work with MySQL and Postgresql.
+known to work with MySQL and PostgreSQL.

 .. versionadded:: 1.2

@@ -905,4 +905,4 @@ Inheritance Loading API

 .. autofunction:: sqlalchemy.orm.with_polymorphic

-.. autofunction:: sqlalchemy.orm.selectin_polymorphic
+.. autofunction:: sqlalchemy.orm.selectin_polymorphic
@@ -391,7 +391,7 @@ SELECT statements, each referring to a subset of rows using the WHERE
 clause, e.g. windowing.   Alternatively, consider using "select IN" eager loading
 which is **potentially** compatible with :meth:`.Query.yield_per`, provided
 that the database driver in use supports multiple, simultaneous cursors
-(SQLite, Postgresql drivers, not MySQL drivers or SQL Server ODBC drivers).
+(SQLite, PostgreSQL drivers, not MySQL drivers or SQL Server ODBC drivers).


 .. _zen_of_eager_loading:
@@ -811,7 +811,7 @@ as of the 1.2 series.   Things to know about this kind of loading include:
  with a top limit on memory use when used with :meth:`.Query.yield_per`.

  Current database drivers that support simultaneous cursors include
-  SQLite, Postgresql.   The MySQL drivers mysqlclient and pymysql currently
+  SQLite, PostgreSQL.   The MySQL drivers mysqlclient and pymysql currently
  **do not** support simultaneous cursors, nor do the ODBC drivers for
  SQL Server.

@@ -819,7 +819,7 @@ as of the 1.2 series.   Things to know about this kind of loading include:
  keys, it must use the "tuple" form of IN, which looks like
  ``WHERE (table.column_a, table.column_b) IN ((?, ?), (?, ?), (?, ?))``.
  This syntax is not supported on every database; currently it is known
-  to be only supported by modern Postgresql and MySQL versions.  Therefore
+  to be only supported by modern PostgreSQL and MySQL versions.  Therefore
  **selectin loading is not platform-agnostic for composite primary keys**.
  There is no special logic in SQLAlchemy to check ahead of time which platforms
  support this syntax or not; if run against a non-supporting platform (such
@@ -345,7 +345,7 @@ outside of the database's usual autoincrement routine. In this case, we have to
 make sure SQLAlchemy can "pre-execute" the default, which means it has to be an
 explicit SQL expression.

-.. note::  This section will will illustrate multiple recipes involving
+.. note::  This section will illustrate multiple recipes involving
   datetime values for MySQL and SQLite, since the datetime datatypes on these
   two  backends have additional idiosyncratic requirements that are useful to
   illustrate.  Keep in mind however that SQLite and MySQL require an explicit
@@ -150,7 +150,7 @@ methods are called.

 The :class:`.Session` also features an older legacy mode of use called
 **autocommit mode**, where a transaction is not started implicitly, and unless
-the the :meth:`.Session.begin` method is invoked, the :class:`.Session` will
+the :meth:`.Session.begin` method is invoked, the :class:`.Session` will
 perform each database operation on a new connection checked out from the
 connection pool, which is then released back to the pool immediately
 after the operation completes.  This refers to
@@ -359,7 +359,7 @@ the generative method :meth:`~.mysql.dml.Insert.on_duplicate_key_update`::

    conn.execute(on_duplicate_key_stmt)

-Unlike Postgresql's "ON CONFLICT" phrase, the "ON DUPLICATE KEY UPDATE"
+Unlike PostgreSQL's "ON CONFLICT" phrase, the "ON DUPLICATE KEY UPDATE"
 phrase will always match on any primary key or unique key, and will always
 perform an UPDATE if there's a match; there are no options for it to raise
 an error or to skip performing an UPDATE.
@@ -189,7 +189,7 @@ The other axis along which SQLite's transactional locking is impacted is
 via the nature of the ``BEGIN`` statement used.   The three varieties
 are "deferred", "immediate", and "exclusive", as described at
 `BEGIN TRANSACTION <http://sqlite.org/lang_transaction.html>`_.   A straight
-``BEGIN`` statement uses the "deferred" mode, where the the database file is
+``BEGIN`` statement uses the "deferred" mode, where the database file is
 not locked until the first read or write operation, and read access remains
 open to other transactions until the first write operation.  But again,
 it is critical to note that the pysqlite driver interferes with this behavior
@@ -2331,7 +2331,7 @@ class Query(object):

        # the right side as given often needs to be adapted.  additionally
        # a lot of things can be wrong with it.  handle all that and
-        # get back the the new effective "right" side
+        # get back the new effective "right" side
        r_info, right, onclause = self._join_check_and_adapt_right_side(
            left, right, onclause, prop, create_aliases,
        )
@@ -3722,7 +3722,7 @@ class Query(object):
            **self._select_args
        )
        # put FOR UPDATE on the inner query, where MySQL will honor it,
-        # as well as if it has an OF so Postgresql can use it.
+        # as well as if it has an OF so PostgreSQL can use it.
        inner._for_update_arg = context._for_update_arg

        for hint in self._with_hints:
@@ -3742,7 +3742,7 @@ class Query(object):
            use_labels=context.labels)

        # Oracle however does not allow FOR UPDATE on the subquery,
-        # and the Oracle dialect ignores it, plus for Postgresql, MySQL
+        # and the Oracle dialect ignores it, plus for PostgreSQL, MySQL
        # we expect that all elements of the row are locked, so also put it
        # on the outside (except in the case of PG when OF is used)
        if context._for_update_arg is not None and \
@@ -1894,13 +1894,13 @@ class JSON(Indexable, TypeEngine):
    Index operations return an expression object whose type defaults to
    :class:`.JSON` by default, so that further JSON-oriented instructions
    may be called upon the result type.   Note that there are backend-specific
-    idiosyncracies here, including that the Postgresql database does not generally
+    idiosyncracies here, including that the PostgreSQL database does not generally
    compare a "json" to a "json" structure without type casts.  These idiosyncracies
-    can be accommodated in a backend-neutral way by by making explicit use
+    can be accommodated in a backend-neutral way by making explicit use
    of the :func:`.cast` and :func:`.type_coerce` constructs.
    Comparison of specific index elements of a :class:`.JSON` object
-    to other objects work best if the **left hand side is CAST to a string**
-    and the **right hand side is rendered as a json string**; a future SQLAlchemy
+    to other objects works best if the **left hand side is CAST to a string**
+    and the **right hand side is rendered as a JSON string**; a future SQLAlchemy
    feature such as a generic "astext" modifier may simplify this at some point:

    * **Compare an element of a JSON structure to a string**::
@@ -66,7 +66,7 @@ def setup_options(make_option):
    make_option("--nomemory", action="store_true", dest="nomemory",
                help="Don't run memory profiling tests")
    make_option("--postgresql-templatedb", type="string",
-                help="name of template database to use for Postgresql "
+                help="name of template database to use for PostgreSQL "
                     "CREATE DATABASE (defaults to current database)")
    make_option("--low-connections", action="store_true",
                dest="low_connections",
@@ -418,7 +418,7 @@ class DefaultRequirements(SuiteRequirements):
        """target system has a strong concept of 'default' schema that can
           be referred to implicitly.

-           basically, Postgresql.
+           basically, PostgreSQL.

        """
        return only_on([
@@ -1858,12 +1858,12 @@ class SchemaTypeTest(fixtures.TestBase):

        is_true(y_copy.type._create_events)

-        # for Postgresql, this will emit CREATE TYPE
+        # for PostgreSQL, this will emit CREATE TYPE
        m.dispatch.before_create(t1, testing.db)
        try:
            eq_(t1.c.y.type.evt_targets, (t1, ))
        finally:
-            # do the drop so that Postgresql emits DROP TYPE
+            # do the drop so that PostgreSQL emits DROP TYPE
            m.dispatch.after_drop(t1, testing.db)

    def test_enum_nonnative_column_copy_transfers_events(self):
@@ -335,7 +335,7 @@ class SelectableTest(

    def test_alias_handles_column_context(self):
        # not quite a use case yet but this is expected to become
-        # prominent w/ Postgresql's tuple functions
+        # prominent w/ PostgreSQL's tuple functions

        stmt = select([table1.c.col1, table1.c.col2])
        a = stmt.alias('a')