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

5 files changed, 10 insertions, 10 deletions

diff --git a/lib/sqlalchemy/dialects/mysql/base.py b/lib/sqlalchemy/dialects/mysql/base.py
index a02155199..d633c2f65 100644
--- a/lib/sqlalchemy/dialects/mysql/base.py
+++ b/lib/sqlalchemy/dialects/mysql/base.py
@@ -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.
diff --git a/lib/sqlalchemy/dialects/sqlite/base.py b/lib/sqlalchemy/dialects/sqlite/base.py
index 566814375..c487af898 100644
--- a/lib/sqlalchemy/dialects/sqlite/base.py
+++ b/lib/sqlalchemy/dialects/sqlite/base.py
@@ -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
diff --git a/lib/sqlalchemy/orm/query.py b/lib/sqlalchemy/orm/query.py
index df8add27d..febf627b4 100644
--- a/lib/sqlalchemy/orm/query.py
+++ b/lib/sqlalchemy/orm/query.py
@@ -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 \
diff --git a/lib/sqlalchemy/sql/sqltypes.py b/lib/sqlalchemy/sql/sqltypes.py
index d40fedc85..c5708940b 100644
--- a/lib/sqlalchemy/sql/sqltypes.py
+++ b/lib/sqlalchemy/sql/sqltypes.py
@@ -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**::
diff --git a/lib/sqlalchemy/testing/plugin/plugin_base.py b/lib/sqlalchemy/testing/plugin/plugin_base.py
index 8939ff7c6..0ffcae093 100644
--- a/lib/sqlalchemy/testing/plugin/plugin_base.py
+++ b/lib/sqlalchemy/testing/plugin/plugin_base.py
@@ -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",