spelling: Postgresql -> PostgreSQL

27 files changed, 168 insertions, 168 deletions

diff --git a/doc/build/changelog/changelog_06.rst b/doc/build/changelog/changelog_06.rst
index 4a00201e7..d1c7fe5db 100644
--- a/doc/build/changelog/changelog_06.rst
+++ b/doc/build/changelog/changelog_06.rst
@@ -543,7 +543,7 @@
       of the auto-generated sequence of a SERIAL column,
       which currently only occurs if implicit_returning=False,
       now accommodates if the table + column name is greater
-      than 63 characters using the same logic Postgresql uses.
+      than 63 characters using the same logic PostgreSQL uses.
 
     .. change::
         :tags: postgresql
@@ -2850,7 +2850,7 @@
         :tags: postgresql
         :tickets: 1071
 
-      Postgresql now reflects sequence names associated with
+      PostgreSQL now reflects sequence names associated with
       SERIAL columns correctly, after the name of the sequence
       has been changed.  Thanks to Kumar McMillan for the patch.
 
@@ -2873,7 +2873,7 @@
         :tags: postgresql
         :tickets: 1769
 
-      Postgresql reflects the name of primary key constraints,
+      PostgreSQL reflects the name of primary key constraints,
       if one exists.
 
     .. change::
@@ -3462,7 +3462,7 @@
       as well as the adaptation of the Python operator into
       a SQL operator, based on the full left/right/operator
       of the given expression.  In particular
-      the date/time/interval system created for Postgresql
+      the date/time/interval system created for PostgreSQL
       EXTRACT in has now been generalized into
       the type system.   The previous behavior which often
       occurred of an expression "column + literal" forcing
@@ -4259,7 +4259,7 @@
 
       returning() support is native to insert(), update(),
       delete(). Implementations of varying levels of
-      functionality exist for Postgresql, Firebird, MSSQL and
+      functionality exist for PostgreSQL, Firebird, MSSQL and
       Oracle. returning() can be called explicitly with column
       expressions which are then returned in the resultset,
       usually via fetchone() or first().
@@ -4280,7 +4280,7 @@
       another will now be grouped with parenthesis - previously,
       the first compound element in the list would not be grouped,
       as SQLite doesn't like a statement to start with
-      parenthesis.   However, Postgresql in particular has
+      parenthesis.   However, PostgreSQL in particular has
       precedence rules regarding INTERSECT, and it is
       more consistent for parenthesis to be applied equally
       to all sub-elements.   So now, the workaround for SQLite
@@ -4586,7 +4586,7 @@
 
       The "start" and "increment" attributes on Sequence now
       generate "START WITH" and "INCREMENT BY" by default,
-      on Oracle and Postgresql.  Firebird doesn't support
+      on Oracle and PostgreSQL.  Firebird doesn't support
       these keywords right now.
 
     .. change::
@@ -5279,7 +5279,7 @@
       optimized, resulting in varying speed improvements:
       Unicode, PickleType, Interval, TypeDecorator, Binary.
       Also the following dbapi-specific implementations have been improved:
-      Time, Date and DateTime on Sqlite, ARRAY on Postgresql,
+      Time, Date and DateTime on Sqlite, ARRAY on PostgreSQL,
       Time on MySQL, Numeric(as_decimal=False) on MySQL, oursql and
       pypostgresql, DateTime on cx_oracle and LOB-based types on cx_oracle.
 
diff --git a/doc/build/changelog/changelog_07.rst b/doc/build/changelog/changelog_07.rst
index fa952f012..a77945fc2 100644
--- a/doc/build/changelog/changelog_07.rst
+++ b/doc/build/changelog/changelog_07.rst
@@ -88,7 +88,7 @@
         :tickets: 2676
         :versions: 0.8.0
 
-      Added support for Postgresql's traditional SUBSTRING
+      Added support for PostgreSQL's traditional SUBSTRING
       function syntax, renders as "SUBSTRING(x FROM y FOR z)"
       when regular ``func.substring()`` is used.
       Courtesy Gunnlaugur Þór Briem.
@@ -885,7 +885,7 @@
         :tickets: 2445
 
       Added new for_update/with_lockmode()
-      options for Postgresql: for_update="read"/
+      options for PostgreSQL: for_update="read"/
       with_lockmode("read"),
       for_update="read_nowait"/
       with_lockmode("read_nowait").
@@ -1873,7 +1873,7 @@
       The update() construct can now accommodate
       multiple tables in the WHERE clause, which will
       render an "UPDATE..FROM" construct, recognized by
-      Postgresql and MSSQL.  When compiled on MySQL,
+      PostgreSQL and MSSQL.  When compiled on MySQL,
       will instead generate "UPDATE t1, t2, ..".  MySQL
       additionally can render against multiple tables in the
       SET clause, if Column objects are used as keys
@@ -1968,7 +1968,7 @@
         :tickets: 1679
 
       a "has_schema" method has been implemented
-      on dialect, but only works on Postgresql so far.
+      on dialect, but only works on PostgreSQL so far.
       Courtesy Manlio Perillo.
 
     .. change::
@@ -2025,7 +2025,7 @@
         :tags: postgresql, bug
         :tickets: 2311
 
-      Postgresql dialect memoizes that an ENUM of a
+      PostgreSQL dialect memoizes that an ENUM of a
       particular name was processed
       during a create/drop sequence.  This allows
       a create/drop sequence to work without any
@@ -3696,7 +3696,7 @@
         :tickets: 2081
 
       REAL has been added to the core types.  Supported
-      by Postgresql, SQL Server, MySQL, SQLite.  Note
+      by PostgreSQL, SQL Server, MySQL, SQLite.  Note
       that the SQL Server and MySQL versions, which
       add extra arguments, are also still available
       from those dialects.
@@ -4348,7 +4348,7 @@
         :tickets: 1069
 
       Query.distinct() now accepts column expressions
-      as \*args, interpreted by the Postgresql dialect
+      as \*args, interpreted by the PostgreSQL dialect
       as DISTINCT ON (<expr>).
 
     .. change::
@@ -4448,7 +4448,7 @@
         :tickets: 1069
 
       select.distinct() now accepts column expressions
-      as \*args, interpreted by the Postgresql dialect
+      as \*args, interpreted by the PostgreSQL dialect
       as DISTINCT ON (<expr>).  Note this was already
       available via passing a list to the `distinct`
       keyword argument to select().
@@ -4531,7 +4531,7 @@
       "isolation_level" argument, sets transaction isolation
       level for that connection only until returned to the
       connection pool, for those backends which support it
-      (SQLite, Postgresql)
+      (SQLite, PostgreSQL)
 
     .. change::
         :tags: sql
@@ -4648,7 +4648,7 @@
       of the auto-generated sequence of a SERIAL column,
       which currently only occurs if implicit_returning=False,
       now accommodates if the table + column name is greater
-      than 63 characters using the same logic Postgresql uses. (also in 0.6.7)
+      than 63 characters using the same logic PostgreSQL uses. (also in 0.6.7)
 
     .. change::
         :tags: postgresql
@@ -4668,7 +4668,7 @@
       'unbounded'.  This also occurs for the VARBINARY type..
 
       This behavior makes these types more closely compatible
-      with Postgresql's VARCHAR type which is similarly unbounded
+      with PostgreSQL's VARCHAR type which is similarly unbounded
       when no length is specified.
 
     .. change::
diff --git a/doc/build/changelog/changelog_08.rst b/doc/build/changelog/changelog_08.rst
index ddf6be5ea..ba5e64e8c 100644
--- a/doc/build/changelog/changelog_08.rst
+++ b/doc/build/changelog/changelog_08.rst
@@ -197,7 +197,7 @@
         :versions: 0.9.4
 
         Fixed regression caused by release 0.8.5 / 0.9.3's compatibility
-        enhancements where index reflection on Postgresql versions specific
+        enhancements where index reflection on PostgreSQL versions specific
         to only the 8.1, 8.2 series again
         broke, surrounding the ever problematic int2vector type.  While
         int2vector supports array operations as of 8.1, apparently it only
@@ -284,8 +284,8 @@
         :tags: postgresql, bug
         :versions: 0.9.3
 
-        Support has been improved for Postgresql reflection behavior on very old
-        (pre 8.1) versions of Postgresql, and potentially other PG engines
+        Support has been improved for PostgreSQL reflection behavior on very old
+        (pre 8.1) versions of PostgreSQL, and potentially other PG engines
         such as Redshift (assuming Redshift reports the version as < 8.1).
         The query for "indexes" as well as "primary keys" relies upon inspecting
         a so-called "int2vector" datatype, which refuses to coerce to an array
@@ -351,10 +351,10 @@
         :tickets: 2291
         :versions: 0.9.3
 
-        Revised this very old issue where the Postgresql "get primary key"
+        Revised this very old issue where the PostgreSQL "get primary key"
         reflection query were updated to take into account primary key constraints
         that were renamed; the newer query fails on very old versions of
-        Postgresql such as version 7, so the old query is restored in those cases
+        PostgreSQL such as version 7, so the old query is restored in those cases
         when server_version_info < (8, 0) is detected.
 
     .. change::
@@ -798,8 +798,8 @@
         :tickets: 2819
         :versions: 0.9.0b1
 
-        Fixed bug where Postgresql version strings that had a prefix preceding
-        the words "Postgresql" or "EnterpriseDB" would not parse.
+        Fixed bug where PostgreSQL version strings that had a prefix preceding
+        the words "PostgreSQL" or "EnterpriseDB" would not parse.
         Courtesy Scott Schaefer.
 
     .. change::
@@ -834,7 +834,7 @@
 
         Added a new flag ``system=True`` to :class:`.Column`, which marks
         the column as a "system" column which is automatically made present
-        by the database (such as Postgresql ``oid`` or ``xmin``).  The
+        by the database (such as PostgreSQL ``oid`` or ``xmin``).  The
         column will be omitted from the ``CREATE TABLE`` statement but will
         otherwise be available for querying.   In addition, the
         :class:`.CreateColumn` construct can be appled to a custom
@@ -942,7 +942,7 @@
         form of a some expressions when referring to the ``.c`` collection
         on a ``select()`` construct, but the ``str()`` form isn't available
         since the element relies on dialect-specific compilation constructs,
-        notably the ``__getitem__()`` operator as used with a Postgresql
+        notably the ``__getitem__()`` operator as used with a PostgreSQL
         ``ARRAY`` element.  The fix also adds a new exception class
         :exc:`.UnsupportedCompilationError` which is raised in those cases
         where a compiler is asked to compile something it doesn't know
@@ -1069,7 +1069,7 @@
         :versions: 0.9.0b1
 
         The behavior of :func:`.extract` has been simplified on the
-        Postgresql dialect to no longer inject a hardcoded ``::timestamp``
+        PostgreSQL dialect to no longer inject a hardcoded ``::timestamp``
         or similar cast into the given expression, as this interfered
         with types such as timezone-aware datetimes, but also
         does not appear to be at all necessary with modern versions
@@ -1103,7 +1103,7 @@
         :versions: 0.9.0b1
 
         Fixed bug where the order of columns in a multi-column
-        Postgresql index would be reflected in the wrong order.
+        PostgreSQL index would be reflected in the wrong order.
         Courtesy Roman Podolyaka.
 
     .. change::
@@ -1167,7 +1167,7 @@
         :tags: feature, postgresql
         :versions: 0.9.0b1
 
-        Support for Postgresql 9.2 range types has been added.
+        Support for PostgreSQL 9.2 range types has been added.
         Currently, no type translation is provided, so works
         directly with strings or psycopg2 2.5 range extension types
         at the moment.  Patch courtesy Chris Withers.
@@ -1463,7 +1463,7 @@
       :tags: bug, postgresql
       :tickets: 2681
 
-      The operators for the Postgresql ARRAY type supports
+      The operators for the PostgreSQL ARRAY type supports
       input types of sets, generators, etc. even when
       a dimension is not specified, by turning the given
       iterable into a collection unconditionally.
@@ -1872,7 +1872,7 @@
       is now copied in all cases when :meth:`.Table.tometadata` happens,
       and if ``inherit_schema=True``, the type will take on the new
       schema name passed to the method.   The ``schema`` is important
-      when used with the Postgresql backend, as the type results in
+      when used with the PostgreSQL backend, as the type results in
       a ``CREATE TYPE`` statement.
 
     .. change::
@@ -2153,7 +2153,7 @@
       The :class:`.Insert` construct now supports multi-valued inserts,
       that is, an INSERT that renders like
       "INSERT INTO table VALUES (...), (...), ...".
-      Supported by Postgresql, SQLite, and MySQL.
+      Supported by PostgreSQL, SQLite, and MySQL.
       Big thanks to Idan Kamara for doing the legwork on this one.
 
       .. seealso::
@@ -2272,7 +2272,7 @@
         :tags: postgresql, feature
         :tickets: 2606
 
-      :class:`.HSTORE` is now available in the Postgresql dialect.
+      :class:`.HSTORE` is now available in the PostgreSQL dialect.
       Will also use psycopg2's extensions if available.  Courtesy
       Audrius Kažukauskas.
 
@@ -3199,7 +3199,7 @@
       the `getitem` operator, i.e. the bracket
       operator in Python.  This is used at first
       to provide index and slice behavior to the
-      Postgresql ARRAY type, and also provides a hook
+      PostgreSQL ARRAY type, and also provides a hook
       for end-user definition of custom __getitem__
       schemes which can be applied at the type
       level as well as within ORM-level custom
@@ -3237,7 +3237,7 @@
       String types.  When present, renders as
       COLLATE <collation>.  This to support the
       COLLATE keyword now supported by several
-      databases including MySQL, SQLite, and Postgresql.
+      databases including MySQL, SQLite, and PostgreSQL.
 
     .. change::
         :tags: change, sql
@@ -3603,7 +3603,7 @@
         :tags: postgresql, feature
         :tickets: 2506
 
-      Added support for the Postgresql ONLY
+      Added support for the PostgreSQL ONLY
       keyword, which can appear corresponding to a
       table in a SELECT, UPDATE, or DELETE statement.
       The phrase is established using with_hint().
@@ -3614,7 +3614,7 @@
         :tickets:
 
       The "ischema_names" dictionary of the
-      Postgresql dialect is "unofficially" customizable.
+      PostgreSQL dialect is "unofficially" customizable.
       Meaning, new types such as PostGIS types can
       be added into this dictionary, and the PG type
       reflection code should be able to handle simple
diff --git a/doc/build/changelog/changelog_09.rst b/doc/build/changelog/changelog_09.rst
index acb836274..c912387cd 100644
--- a/doc/build/changelog/changelog_09.rst
+++ b/doc/build/changelog/changelog_09.rst
@@ -194,7 +194,7 @@
         :pullreq: bitbucket:45
         :versions: 1.0.0b1
 
-        Added support for the ``CONCURRENTLY`` keyword with Postgresql
+        Added support for the ``CONCURRENTLY`` keyword with PostgreSQL
         indexes, established using ``postgresql_concurrently``.  Pull
         request courtesy Iuri de Silvio.
 
@@ -312,7 +312,7 @@
         :tickets: 2940
         :versions: 1.0.0b1
 
-        Repaired support for Postgresql UUID types in conjunction with
+        Repaired support for PostgreSQL UUID types in conjunction with
         the ARRAY type when using psycopg2.  The psycopg2 dialect now
         employs use of the psycopg2.extras.register_uuid() hook
         so that UUID values are always passed to/from the DBAPI as
@@ -331,7 +331,7 @@
         additionally, the newly added psycopg2 extension
         ``extras.register_default_jsonb`` is used to establish a JSON
         deserializer passed to the dialect via the ``json_deserializer``
-        argument.  Also repaired the Postgresql integration tests which
+        argument.  Also repaired the PostgreSQL integration tests which
         weren't actually round-tripping the JSONB type as opposed to the
         JSON type.  Pull request courtesy Mateusz Susik.
 
@@ -374,7 +374,7 @@
         :versions: 1.0.0b1
         :tickets: 3174
 
-        Fixed bug where Postgresql dialect would fail to render an
+        Fixed bug where PostgreSQL dialect would fail to render an
         expression in an :class:`.Index` that did not correspond directly
         to a table-bound column; typically when a :func:`.text` construct
         was one of the expressions within the index; or could misinterpret the
@@ -770,7 +770,7 @@
         :versions: 1.0.0b1
         :tickets: 3159
 
-        Fixed bug where Postgresql JSON type was not able to persist or
+        Fixed bug where PostgreSQL JSON type was not able to persist or
         otherwise render a SQL NULL column value, rather than a JSON-encoded
         ``'null'``.  To support this case, changes are as follows:
 
@@ -891,7 +891,7 @@
         then force all :class:`.Boolean` and :class:`.Enum` types to
         require names as well, as these implicitly create a
         constraint, even if the ultimate target backend were one that does
-        not require generation of the constraint such as Postgresql.
+        not require generation of the constraint such as PostgreSQL.
         The mechanics of naming conventions for these particular
         constraints has been reorganized such that the naming
         determination is done at DDL compile time, rather than at
@@ -990,7 +990,7 @@
         :versions: 1.0.0b1
         :pullreq: github:101
 
-        Added support for Postgresql JSONB via :class:`.JSONB`.  Pull request
+        Added support for PostgreSQL JSONB via :class:`.JSONB`.  Pull request
         courtesy Damian Dimmich.
 
     .. change::
@@ -1103,7 +1103,7 @@
         :tickets: 3002
         :versions: 1.0.0b1
 
-        Added a new type :class:`.postgresql.OID` to the Postgresql dialect.
+        Added a new type :class:`.postgresql.OID` to the PostgreSQL dialect.
         While "oid" is generally a private type within PG that is not exposed
         in modern versions, there are some PG use cases such as large object
         support where these types might be exposed, as well as within some
@@ -1231,11 +1231,11 @@
         :pullreq: bitbucket:18
         :versions: 1.0.0b1
 
-        Added a new flag :paramref:`.ARRAY.zero_indexes` to the Postgresql
+        Added a new flag :paramref:`.ARRAY.zero_indexes` to the PostgreSQL
         :class:`.ARRAY` type.  When set to ``True``, a value of one will be
         added to all array index values before passing to the database, allowing
         better interoperability between Python style zero-based indexes and
-        Postgresql one-based indexes.  Pull request courtesy Alexey Terentev.
+        PostgreSQL one-based indexes.  Pull request courtesy Alexey Terentev.
 
     .. change::
         :tags: bug, engine
@@ -1957,7 +1957,7 @@
         Added a new dialect-level argument ``postgresql_ignore_search_path``;
         this argument is accepted by both the :class:`.Table` constructor
         as well as by the :meth:`.MetaData.reflect` method.  When in use
-        against Postgresql, a foreign-key referenced table which specifies
+        against PostgreSQL, a foreign-key referenced table which specifies
         a remote schema name will retain that schema name even if the name
         is present in the ``search_path``; the default behavior since 0.7.3
         has been that schemas present in ``search_path`` would not be copied
@@ -2500,7 +2500,7 @@
         :tickets: 2581
         :pullreq: github:50
 
-        Support for Postgresql JSON has been added, using the new
+        Support for PostgreSQL JSON has been added, using the new
         :class:`.JSON` type.   Huge thanks to Nathan Rice for
         implementing and testing this.
 
@@ -2550,7 +2550,7 @@
         :tags: feature, postgresql
         :pullreq: bitbucket:8
 
-        Added support for Postgresql TSVECTOR via the
+        Added support for PostgreSQL TSVECTOR via the
         :class:`.postgresql.TSVECTOR` type.  Pull request courtesy
         Noufal Ibrahim.
 
@@ -2825,8 +2825,8 @@
         :tags: feature, sql, postgresql, mysql
         :tickets: 2183
 
-        The Postgresql and MySQL dialects now support reflection/inspection
-        of foreign key options, including ON UPDATE, ON DELETE.  Postgresql
+        The PostgreSQL and MySQL dialects now support reflection/inspection
+        of foreign key options, including ON UPDATE, ON DELETE.  PostgreSQL
         also reflects MATCH, DEFERRABLE, and INITIALLY.  Coutesy ijl.
 
     .. change::
@@ -2936,7 +2936,7 @@
 
         Added support for rendering ``SMALLSERIAL`` when a :class:`.SmallInteger`
         type is used on a primary key autoincrement column, based on server
-        version detection of Postgresql version 9.2 or greater.
+        version detection of PostgreSQL version 9.2 or greater.
 
     .. change::
         :tags: feature, mysql
diff --git a/doc/build/changelog/changelog_10.rst b/doc/build/changelog/changelog_10.rst
index 887c5c61d..8a061cdac 100644
--- a/doc/build/changelog/changelog_10.rst
+++ b/doc/build/changelog/changelog_10.rst
@@ -133,7 +133,7 @@
         :versions: 1.1.0b3
 
         Fixed bug whereby :class:`.TypeDecorator` and :class:`.Variant`
-        types were not deeply inspected enough by the Postgresql dialect
+        types were not deeply inspected enough by the PostgreSQL dialect
         to determine if SMALLSERIAL or BIGSERIAL needed to be rendered
         rather than SERIAL.
 
@@ -384,7 +384,7 @@
 
         Fixed bug in :func:`.expression.text` construct where a double-colon
         expression would not escape properly, e.g. ``some\:\:expr``, as is most
-        commonly required when rendering Postgresql-style CAST expressions.
+        commonly required when rendering PostgreSQL-style CAST expressions.
 
     .. change::
         :tags: bug, sql
@@ -627,7 +627,7 @@
 
         Fixed bug where CREATE TABLE with a no-column table, but a constraint
         such as a CHECK constraint would render an erroneous comma in the
-        definition; this scenario can occur such as with a Postgresql
+        definition; this scenario can occur such as with a PostgreSQL
         INHERITS table that has no columns of its own.
 
     .. change::
@@ -645,7 +645,7 @@
         :tickets: 3573
 
 
-        Fixed issue where the "FOR UPDATE OF" Postgresql-specific SELECT
+        Fixed issue where the "FOR UPDATE OF" PostgreSQL-specific SELECT
         modifier would fail if the referred table had a schema qualifier;
         PG needs the schema name to be omitted.  Pull request courtesy
         Diana Clarke.
@@ -782,7 +782,7 @@
 
         Fixed regression in 1.0 where new feature of using "executemany"
         for UPDATE statements in the ORM (e.g. :ref:`feature_updatemany`)
-        would break on Postgresql and other RETURNING backends
+        would break on PostgreSQL and other RETURNING backends
         when using server-side version generation
         schemes, as the server side value is retrieved via RETURNING which
         is not supported with executemany.
@@ -878,11 +878,11 @@
         :pullreq: github:190
 
 
-        An adjustment to the new Postgresql feature of reflecting storage
+        An adjustment to the new PostgreSQL feature of reflecting storage
         options and USING of :ticket:`3455` released in 1.0.6,
-        to disable the feature for Postgresql versions < 8.2 where the
+        to disable the feature for PostgreSQL versions < 8.2 where the
         ``reloptions`` column is not provided; this allows Amazon Redshift
-        to again work as it is based on an 8.0.x version of Postgresql.
+        to again work as it is based on an 8.0.x version of PostgreSQL.
         Fix courtesy Pete Hollobon.
 
 
@@ -967,7 +967,7 @@
         :pullreq: github:186
 
         Added support for the MINVALUE, MAXVALUE, NO MINVALUE, NO MAXVALUE,
-        and CYCLE arguments for CREATE SEQUENCE as supported by Postgresql
+        and CYCLE arguments for CREATE SEQUENCE as supported by PostgreSQL
         and Oracle.  Pull request courtesy jakeogh.
 
     .. change::
@@ -1552,7 +1552,7 @@
         label name for all backends, as described in :ref:`migration_1068`,
         even though 1.0 includes a rewrite of this logic as part of
         :ticket:`2992`.  As far
-        as emitting GROUP BY against a simple label, even Postgresql has
+        as emitting GROUP BY against a simple label, even PostgreSQL has
         cases where it will raise an error even though the label to group
         on should be apparent, so it is clear that GROUP BY should never
         be rendered in this way automatically.
@@ -1820,9 +1820,9 @@
         :tickets: 3343
 
         Fixed bug where updated PG index reflection as a result of
-        :ticket:`3184` would cause index operations to fail on Postgresql
+        :ticket:`3184` would cause index operations to fail on PostgreSQL
         versions 8.4 and earlier.  The enhancements are now
-        disabled when using an older version of Postgresql.
+        disabled when using an older version of PostgreSQL.
 
     .. change::
         :tags: bug, sql
@@ -2003,7 +2003,7 @@
         :tags: bug, postgresql
         :tickets: 3319
 
-        The Postgresql :class:`.postgresql.ENUM` type will emit a
+        The PostgreSQL :class:`.postgresql.ENUM` type will emit a
         DROP TYPE instruction when a plain ``table.drop()`` is called,
         assuming the object is not associated directly with a
         :class:`.MetaData` object.   In order to accommodate the use case of
@@ -2011,7 +2011,7 @@
         be associated directly with the :class:`.MetaData` object; in this
         case the type will only be created at the metadata level, or if
         created directly.  The rules for create/drop of
-        Postgresql enumerated types have been highly reworked in general.
+        PostgreSQL enumerated types have been highly reworked in general.
 
         .. seealso::
 
@@ -2494,7 +2494,7 @@
         ``pg_catalog.pg_table_is_visible(c.oid)``, rather than testing
         for an exact schema match, when the schema name is None; this
         so that the method will also illustrate that temporary tables
-        are present.  Note that this is a behavioral change, as Postgresql
+        are present.  Note that this is a behavioral change, as PostgreSQL
         allows a non-temporary table to silently overwrite an existing
         temporary table of the same name, so this changes the behavior
         of ``checkfirst`` in that unusual scenario.
@@ -2757,13 +2757,13 @@
         The :class:`.UniqueConstraint` construct is now included when
         reflecting a :class:`.Table` object, for databases where this
         is applicable.  In order to achieve this
-        with sufficient accuracy, MySQL and Postgresql now contain features
+        with sufficient accuracy, MySQL and PostgreSQL now contain features
         that correct for the duplication of indexes and unique constraints
         when reflecting tables, indexes, and constraints.
         In the case of MySQL, there is not actually a "unique constraint"
         concept independent of a "unique index", so for this backend
         :class:`.UniqueConstraint` continues to remain non-present for a
-        reflected :class:`.Table`.  For Postgresql, the query used to
+        reflected :class:`.Table`.  For PostgreSQL, the query used to
         detect indexes against ``pg_index`` has been improved to check for
         the same construct in ``pg_constraint``, and the implicitly
         constructed unique index is not included with a
@@ -2772,7 +2772,7 @@
         In both cases, the  :meth:`.Inspector.get_indexes` and the
         :meth:`.Inspector.get_unique_constraints` methods return both
         constructs individually, but include a new token
-        ``duplicates_constraint`` in the case of Postgresql or
+        ``duplicates_constraint`` in the case of PostgreSQL or
         ``duplicates_index`` in the case
         of MySQL to indicate when this condition is detected.
         Pull request courtesy Johannes Erdfelt.
@@ -2786,7 +2786,7 @@
         :pullreq: github:134
 
         Added support for the FILTER keyword as applied to aggregate
-        functions, supported by Postgresql 9.4.   Pull request
+        functions, supported by PostgreSQL 9.4.   Pull request
         courtesy Ilja Everilä.
 
         .. seealso::
@@ -2856,7 +2856,7 @@
         for a non-nullable or ``ondelete="SET NULL"`` for a nullable set
         of columns, the argument ``passive_deletes=True`` is also added to the
         relationship.  Note that not all backends support reflection of
-        ondelete, but backends that do include Postgresql and MySQL.
+        ondelete, but backends that do include PostgreSQL and MySQL.
 
     .. change::
         :tags: feature, sql
@@ -2907,7 +2907,7 @@
         and foreign tables, as well as support for materialized views
         within :meth:`.Inspector.get_view_names`, and a new method
         :meth:`.PGInspector.get_foreign_table_names` available on the
-        Postgresql version of :class:`.Inspector`.  Pull request courtesy
+        PostgreSQL version of :class:`.Inspector`.  Pull request courtesy
         Rodrigo Menezes.
 
         .. seealso::
@@ -3252,7 +3252,7 @@
         :pullreq: github:126
 
         Added new method :meth:`.PGInspector.get_enums`, when using the
-        inspector for Postgresql will provide a list of ENUM types.
+        inspector for PostgreSQL will provide a list of ENUM types.
         Pull request courtesy Ilya Pekelny.
 
     .. change::
diff --git a/doc/build/changelog/changelog_11.rst b/doc/build/changelog/changelog_11.rst
index a8d73bbe4..5a1f5c462 100644
--- a/doc/build/changelog/changelog_11.rst
+++ b/doc/build/changelog/changelog_11.rst
@@ -132,10 +132,10 @@
         :tags: bug, sql, postgresql
         :tickets: 3806
 
-        Added compiler-level flags used by Postgresql to place additional
+        Added compiler-level flags used by PostgreSQL to place additional
         parenthesis than would normally be generated by precedence rules
         around operations involving JSON, HSTORE indexing operators as well as
-        within their operands since it has been observed that Postgresql's
+        within their operands since it has been observed that PostgreSQL's
         precedence rules for at least the HSTORE indexing operator is not
         consistent between 9.4 and 9.5.
 
@@ -259,7 +259,7 @@
         Fixed regression in JSON datatypes where the "literal processor" for
         a JSON index value would not be invoked.  The native String and Integer
         datatypes are now called upon from within the JSONIndexType
-        and JSONPathType.  This is applied to the generic, Postgresql, and
+        and JSONPathType.  This is applied to the generic, PostgreSQL, and
         MySQL JSON types and also has a dependency on :ticket:`3766`.
 
     .. change::
diff --git a/doc/build/changelog/migration_06.rst b/doc/build/changelog/migration_06.rst
index e41446de5..c3d0df1f3 100644
--- a/doc/build/changelog/migration_06.rst
+++ b/doc/build/changelog/migration_06.rst
@@ -68,7 +68,7 @@ The URL format used by ``create_engine()`` has been enhanced
 to handle any number of DBAPIs for a particular backend,
 using a scheme that is inspired by that of JDBC.   The
 previous format still works, and will select a "default"
-DBAPI implementation, such as the Postgresql URL below that
+DBAPI implementation, such as the PostgreSQL URL below that
 will use psycopg2:
 
 ::
@@ -306,7 +306,7 @@ A rule that was designed to help SQLite has been removed,
 that of the first compound element within another compound
 (such as, a ``union()`` inside of an ``except_()``) wouldn't
 be parenthesized.   This is inconsistent and produces the
-wrong results on Postgresql, which has precedence rules
+wrong results on PostgreSQL, which has precedence rules
 regarding INTERSECTION, and its generally a surprise.   When
 using complex composites with SQLite, you now need to turn
 the first element into a subquery (which is also compatible
@@ -572,7 +572,7 @@ To use an inspector:
 
 the ``from_engine()`` method will in some cases provide a
 backend-specific inspector with additional capabilities,
-such as that of Postgresql which provides a
+such as that of PostgreSQL which provides a
 ``get_table_oid()`` method:
 
 ::
@@ -588,7 +588,7 @@ RETURNING Support
 
 The ``insert()``, ``update()`` and ``delete()`` constructs
 now support a ``returning()`` method, which corresponds to
-the SQL RETURNING clause as supported by Postgresql, Oracle,
+the SQL RETURNING clause as supported by PostgreSQL, Oracle,
 MS-SQL, and Firebird.   It is not supported for any other
 backend at this time.
 
@@ -747,7 +747,7 @@ Note that the ``assert_unicode`` flag is now deprecated.
 SQLAlchemy allows the DBAPI and backend database in use to
 handle Unicode parameters when available, and does not add
 operational overhead by checking the incoming type; modern
-systems like sqlite and Postgresql will raise an encoding
+systems like sqlite and PostgreSQL will raise an encoding
 error on their end if invalid data is passed.  In those
 cases where SQLAlchemy does need to coerce a bind parameter
 from Python Unicode to an encoded string, or when the
@@ -766,13 +766,13 @@ default, this type generates a ``VARCHAR`` using the size of
 the largest label, and applies a CHECK constraint to the
 table within the CREATE TABLE statement.   When using MySQL,
 the type by default uses MySQL's ENUM type, and when using
-Postgresql the type will generate a user defined type using
+PostgreSQL the type will generate a user defined type using
 ``CREATE TYPE <mytype> AS ENUM``.  In order to create the
-type using Postgresql, the ``name`` parameter must be
+type using PostgreSQL, the ``name`` parameter must be
 specified to the constructor.  The type also accepts a
 ``native_enum=False`` option which will issue the
 VARCHAR/CHECK strategy for all databases.  Note that
-Postgresql ENUM types currently don't work with pg8000 or
+PostgreSQL ENUM types currently don't work with pg8000 or
 zxjdbc.
 
 Reflection Returns Dialect-Specific Types
@@ -958,7 +958,7 @@ innerjoin=True on relation, joinedload
 
 Joined-eagerly loaded scalars and collections can now be
 instructed to use INNER JOIN instead of OUTER JOIN.   On
-Postgresql this is observed to provide a 300-600% speedup on
+PostgreSQL this is observed to provide a 300-600% speedup on
 some queries.   Set this flag for any many-to-one which is
 on a NOT NULLable foreign key, and similarly for any
 collection where related items are guaranteed to exist.
@@ -1049,7 +1049,7 @@ Mutable Primary Keys with Joined Table Inheritance
 
 A joined table inheritance config where the child table has
 a PK that foreign keys to the parent PK can now be updated
-on a CASCADE-capable database like Postgresql.
+on a CASCADE-capable database like PostgreSQL.
 ``mapper()`` now has an option ``passive_updates=True``
 which indicates this foreign key is updated automatically.
 If on a non-cascading database like SQLite or MySQL/MyISAM,
diff --git a/doc/build/changelog/migration_07.rst b/doc/build/changelog/migration_07.rst
index a60151d8d..9c4ba3f81 100644
--- a/doc/build/changelog/migration_07.rst
+++ b/doc/build/changelog/migration_07.rst
@@ -310,14 +310,14 @@ These are implemented as an extension to the ``asc()`` and
 
 :ticket:`723`
 
-select.distinct(), query.distinct() accepts \*args for Postgresql DISTINCT ON
+select.distinct(), query.distinct() accepts \*args for PostgreSQL DISTINCT ON
 -----------------------------------------------------------------------------
 
 This was already available by passing a list of expressions
 to the ``distinct`` keyword argument of ``select()``, the
 ``distinct()`` method of ``select()`` and ``Query`` now
 accept positional arguments which are rendered as DISTINCT
-ON when a Postgresql backend is used.
+ON when a PostgreSQL backend is used.
 
 `distinct() <http://www.sqlalchemy.org/docs/07/core/expressi
 on_api.html#sqlalchemy.sql.expression.Select.distinct>`_
@@ -367,9 +367,9 @@ A "window function" provides to a statement information
 about the result set as it's produced. This allows criteria
 against various things like "row number", "rank" and so
 forth. They are known to be supported at least by
-Postgresql, SQL Server and Oracle, possibly others.
+PostgreSQL, SQL Server and Oracle, possibly others.
 
-The best introduction to window functions is on Postgresql's
+The best introduction to window functions is on PostgreSQL's
 site, where window functions have been supported since
 version 8.4:
 
@@ -425,7 +425,7 @@ The default isolation level is set using the
 ``isolation_level`` argument to ``create_engine()``.
 
 Transaction isolation support is currently only supported by
-the Postgresql and SQLite backends.
+the PostgreSQL and SQLite backends.
 
 `execution_options() <http://www.sqlalchemy.org/docs/07/core
 /connections.html#sqlalchemy.engine.base.Connection.executio
@@ -749,7 +749,7 @@ MS-SQL - ``String``/``Unicode``/``VARCHAR``/``NVARCHAR``/``VARBINARY`` emit "max
 On the MS-SQL backend, the String/Unicode types, and their
 counterparts VARCHAR/ NVARCHAR, as well as VARBINARY
 (:ticket:`1833`) emit "max" as the length when no length is
-specified. This makes it more compatible with Postgresql's
+specified. This makes it more compatible with PostgreSQL's
 VARCHAR type which is similarly unbounded when no length
 specified.   SQL Server defaults the length on these types
 to '1' when no length is specified.
diff --git a/doc/build/changelog/migration_08.rst b/doc/build/changelog/migration_08.rst
index 3dfd9a171..19faafa89 100644
--- a/doc/build/changelog/migration_08.rst
+++ b/doc/build/changelog/migration_08.rst
@@ -669,8 +669,8 @@ The new type is usable like any other type:
 
 
 New features which have come from this immediately include
-support for Postgresql's HSTORE type, as well as new
-operations associated with Postgresql's ARRAY
+support for PostgreSQL's HSTORE type, as well as new
+operations associated with PostgreSQL's ARRAY
 type.    It also paves the way for existing types to acquire
 lots more operators that are specific to those types, such
 as more string, integer and date operators.
@@ -691,7 +691,7 @@ Multiple-VALUES support for Insert
 The :meth:`.Insert.values` method now supports a list of dictionaries,
 which will render a multi-VALUES statement such as
 ``VALUES (<row1>), (<row2>), ...``.  This is only relevant to backends which
-support this syntax, including Postgresql, SQLite, and MySQL.  It is
+support this syntax, including PostgreSQL, SQLite, and MySQL.  It is
 not the same thing as the usual ``executemany()`` style of INSERT which
 remains unchanged::
 
@@ -804,10 +804,10 @@ against a particular target selectable::
 
     :meth:`.Select.correlate_except`
 
-Postgresql HSTORE type
+PostgreSQL HSTORE type
 ----------------------
 
-Support for Postgresql's ``HSTORE`` type is now available as
+Support for PostgreSQL's ``HSTORE`` type is now available as
 :class:`.postgresql.HSTORE`.   This type makes great usage
 of the new operator system to provide a full range of operators
 for HSTORE types, including index access, concatenation,
@@ -840,7 +840,7 @@ and containment methods such as
 
 :ticket:`2606`
 
-Enhanced Postgresql ARRAY type
+Enhanced PostgreSQL ARRAY type
 ------------------------------
 
 The :class:`.postgresql.ARRAY` type will accept an optional
@@ -939,7 +939,7 @@ Huge thanks to Nate Dub for the sprinting on this at Pycon 2012.
 
 :ticket:`2363`
 
-"COLLATE" supported across all dialects; in particular MySQL, Postgresql, SQLite
+"COLLATE" supported across all dialects; in particular MySQL, PostgreSQL, SQLite
 --------------------------------------------------------------------------------
 
 The "collate" keyword, long accepted by the MySQL dialect, is now established
@@ -1079,7 +1079,7 @@ The new behavior allows the following test case to work::
     from sqlalchemy import create_engine
     from sqlalchemy.orm import Session
 
-    # note we're using Postgresql to ensure that referential integrity
+    # note we're using PostgreSQL to ensure that referential integrity
     # is enforced, for demonstration purposes.
     e = create_engine("postgresql://scott:tiger@localhost/test", echo=True)
 
diff --git a/doc/build/changelog/migration_09.rst b/doc/build/changelog/migration_09.rst
index 0c0281a83..2ec7fc3e5 100644
--- a/doc/build/changelog/migration_09.rst
+++ b/doc/build/changelog/migration_09.rst
@@ -597,7 +597,7 @@ generated::
 
 .. _migration_2878:
 
-Postgresql CREATE TYPE <x> AS ENUM now applies quoting to values
+PostgreSQL CREATE TYPE <x> AS ENUM now applies quoting to values
 ----------------------------------------------------------------
 
 The :class:`.postgresql.ENUM` type will now apply escaping to single quote
@@ -879,7 +879,7 @@ New FOR UPDATE support on ``select()``, ``Query()``
 
 An attempt is made to simplify the specification of the ``FOR UPDATE``
 clause on ``SELECT`` statements made within Core and ORM, and support is added
-for the ``FOR UPDATE OF`` SQL supported by Postgresql and Oracle.
+for the ``FOR UPDATE OF`` SQL supported by PostgreSQL and Oracle.
 
 Using the core :meth:`.GenerativeSelect.with_for_update`, options like ``FOR SHARE`` and
 ``NOWAIT`` can be specified individually, rather than linking to arbitrary
@@ -976,11 +976,11 @@ identifier, or alternatively fetch the version identifier
 from each row at the same time the INSERT or UPDATE is emitted.   When using a
 server-generated version identifier, it is strongly
 recommended that this feature be used only on a backend with strong RETURNING
-support (Postgresql, SQL Server; Oracle also supports RETURNING but the cx_oracle
+support (PostgreSQL, SQL Server; Oracle also supports RETURNING but the cx_oracle
 driver has only limited support), else the additional SELECT statements will
 add significant performance
 overhead.   The example provided at :ref:`server_side_version_counter` illustrates
-the usage of the Postgresql ``xmin`` system column in order to integrate it with
+the usage of the PostgreSQL ``xmin`` system column in order to integrate it with
 the ORM's versioning feature.
 
 .. seealso::
@@ -1033,10 +1033,10 @@ from a backref::
 :ticket:`1535`
 
 
-Postgresql JSON Type
+PostgreSQL JSON Type
 --------------------
 
-The Postgresql dialect now features a :class:`.postgresql.JSON` type to
+The PostgreSQL dialect now features a :class:`.postgresql.JSON` type to
 complement the :class:`.postgresql.HSTORE` type.
 
 .. seealso::
@@ -1149,7 +1149,7 @@ but today it seems clear every database tested except SQLite now supports it
 (Oracle 8, a very old database, doesn't support the JOIN keyword at all,
 but SQLAlchemy has always had a simple rewriting scheme in place for Oracle's syntax).
 To make matters worse, SQLAlchemy's usual workaround of applying a
-SELECT often degrades performance on platforms like Postgresql and MySQL::
+SELECT often degrades performance on platforms like PostgreSQL and MySQL::
 
     SELECT a.*, anon_1.* FROM a LEFT OUTER JOIN (
                     SELECT b.id AS b_id, c.id AS c_id
@@ -1335,7 +1335,7 @@ immediately within the flush process.
 
 In 0.9, as a result of the version id enhancements, ``eager_defaults`` can now
 emit a RETURNING clause for these values, so on a backend with strong RETURNING
-support in particular Postgresql, the ORM can fetch newly generated default
+support in particular PostgreSQL, the ORM can fetch newly generated default
 and SQL expression values inline with the INSERT or UPDATE.  ``eager_defaults``,
 when enabled, makes use of RETURNING automatically when the target backend
 and :class:`.Table` supports "implicit returning".
diff --git a/doc/build/changelog/migration_10.rst b/doc/build/changelog/migration_10.rst
index 56b79c88a..189f70cd4 100644
--- a/doc/build/changelog/migration_10.rst
+++ b/doc/build/changelog/migration_10.rst
@@ -896,12 +896,12 @@ UniqueConstraint is now part of the Table reflection process
 A :class:`.Table` object populated using ``autoload=True`` will now
 include :class:`.UniqueConstraint` constructs as well as
 :class:`.Index` constructs.  This logic has a few caveats for
-Postgresql and Mysql:
+PostgreSQL and Mysql:
 
-Postgresql
+PostgreSQL
 ^^^^^^^^^^
 
-Postgresql has the behavior such that when a UNIQUE constraint is
+PostgreSQL has the behavior such that when a UNIQUE constraint is
 created, it implicitly creates a UNIQUE INDEX corresponding to that
 constraint as well. The :meth:`.Inspector.get_indexes` and the
 :meth:`.Inspector.get_unique_constraints` methods will continue to
@@ -1960,7 +1960,7 @@ The output does what we say, but again it warns us::
 The above behavior applies to all those places where we might want to refer
 to a so-called "label reference"; ORDER BY and GROUP BY, but also within an
 OVER clause as well as a DISTINCT ON clause that refers to columns (e.g. the
-Postgresql syntax).
+PostgreSQL syntax).
 
 We can still specify any arbitrary expression for ORDER BY or others using
 :func:`.text`::
@@ -2209,7 +2209,7 @@ reflection from temp tables as well, which is :ticket:`3203`.
 
 :ticket:`3204`
 
-Dialect Improvements and Changes - Postgresql
+Dialect Improvements and Changes - PostgreSQL
 =============================================
 
 .. _change_3319:
@@ -2217,7 +2217,7 @@ Dialect Improvements and Changes - Postgresql
 Overhaul of ENUM type create/drop rules
 ---------------------------------------
 
-The rules for Postgresql :class:`.postgresql.ENUM` have been made more strict
+The rules for PostgreSQL :class:`.postgresql.ENUM` have been made more strict
 with regards to creating and dropping of the TYPE.
 
 An :class:`.postgresql.ENUM` that is created **without** being explicitly
@@ -2263,7 +2263,7 @@ flag::
 
 :ticket:`3319`
 
-New Postgresql Table options
+New PostgreSQL Table options
 -----------------------------
 
 Added support for PG table options TABLESPACE, ON COMMIT,
@@ -2278,11 +2278,11 @@ the :class:`.Table` construct.
 
 .. _feature_get_enums:
 
-New get_enums() method with Postgresql Dialect
+New get_enums() method with PostgreSQL Dialect
 ----------------------------------------------
 
 The :func:`.inspect` method returns a :class:`.PGInspector` object in the
-case of Postgresql, which includes a new :meth:`.PGInspector.get_enums`
+case of PostgreSQL, which includes a new :meth:`.PGInspector.get_enums`
 method that returns information on all available ``ENUM`` types::
 
     from sqlalchemy import inspect, create_engine
@@ -2297,7 +2297,7 @@ method that returns information on all available ``ENUM`` types::
 
 .. _feature_2891:
 
-Postgresql Dialect reflects Materialized Views, Foreign Tables
+PostgreSQL Dialect reflects Materialized Views, Foreign Tables
 --------------------------------------------------------------
 
 Changes are as follows:
@@ -2308,12 +2308,12 @@ Changes are as follows:
 * :meth:`.Inspector.get_view_names` will return plain and materialized view
   names.
 
-* :meth:`.Inspector.get_table_names` does **not** change for Postgresql, it
+* :meth:`.Inspector.get_table_names` does **not** change for PostgreSQL, it
   continues to return only the names of plain tables.
 
 * A new method :meth:`.PGInspector.get_foreign_table_names` is added which
   will return the names of tables that are specifically marked as "foreign"
-  in the Postgresql schema tables.
+  in the PostgreSQL schema tables.
 
 The change to reflection involves adding ``'m'`` and ``'f'`` to the list
 of qualifiers we use when querying ``pg_class.relkind``, but this change
@@ -2324,7 +2324,7 @@ running 0.9 in production.
 
 .. _change_3264:
 
-Postgresql ``has_table()`` now works for temporary tables
+PostgreSQL ``has_table()`` now works for temporary tables
 ---------------------------------------------------------
 
 This is a simple fix such that "has table" for temporary tables now works,
@@ -2348,7 +2348,7 @@ so that code like the following may proceed::
         user_tmp.create(conn, checkfirst=True)
 
 The very unlikely case that this behavior will cause a non-failing application
-to behave differently, is because Postgresql allows a non-temporary table
+to behave differently, is because PostgreSQL allows a non-temporary table
 to silently overwrite a temporary table.  So code like the following will
 now act completely differently, no longer creating the real table following
 the temporary table::
@@ -2382,11 +2382,11 @@ the temporary table::
 
 .. _feature_gh134:
 
-Postgresql FILTER keyword
+PostgreSQL FILTER keyword
 -------------------------
 
 The SQL standard FILTER keyword for aggregate functions is now supported
-by Postgresql as of 9.4.  SQLAlchemy allows this using
+by PostgreSQL as of 9.4.  SQLAlchemy allows this using
 :meth:`.FunctionElement.filter`::
 
     func.count(1).filter(True)
diff --git a/doc/build/changelog/migration_11.rst b/doc/build/changelog/migration_11.rst
index 3485b0e83..eddb2030b 100644
--- a/doc/build/changelog/migration_11.rst
+++ b/doc/build/changelog/migration_11.rst
@@ -2391,7 +2391,7 @@ The JSON cast() operation now requires ``.astext`` is called explicitly
 As part of the changes in :ref:`change_3503`, the workings of the
 :meth:`.ColumnElement.cast` operator on :class:`.postgresql.JSON` and
 :class:`.postgresql.JSONB` no longer implicitly invoke the
-:attr:`.postgresql.JSON.Comparator.astext` modifier; Postgresql's JSON/JSONB types
+:attr:`.postgresql.JSON.Comparator.astext` modifier; PostgreSQL's JSON/JSONB types
 support CAST operations to each other without the "astext" aspect.
 
 This means that in most cases, an application that was doing this::
diff --git a/doc/build/core/constraints.rst b/doc/build/core/constraints.rst
index bf47a5b61..b350038b6 100644
--- a/doc/build/core/constraints.rst
+++ b/doc/build/core/constraints.rst
@@ -145,7 +145,7 @@ most forms of ALTER.  Given a schema like::
     )
 
 When we call upon :meth:`.MetaData.create_all` on a backend such as the
-Postgresql backend, the cycle between these two tables is resolved and the
+PostgreSQL backend, the cycle between these two tables is resolved and the
 constraints are created separately:
 
 .. sourcecode:: pycon+sql
@@ -671,7 +671,7 @@ The above table will produce the constraint name ``ck_foo_flag_bool``::
     )
 
 The :class:`.SchemaType` classes use special internal symbols so that
-the naming convention is only determined at DDL compile time.  On Postgresql,
+the naming convention is only determined at DDL compile time.  On PostgreSQL,
 there's a native BOOLEAN type, so the CHECK constraint of :class:`.Boolean`
 is not needed; we are safe to set up a :class:`.Boolean` type without a
 name, even though a naming convention is in place for check constraints.
@@ -839,7 +839,7 @@ value, the :meth:`.ColumnElement.desc` modifier may be used::
 
     Index('someindex', mytable.c.somecol.desc())
 
-Or with a backend that supports functional indexes such as Postgresql,
+Or with a backend that supports functional indexes such as PostgreSQL,
 a "case insensitive" index can be created using the ``lower()`` function::
 
     from sqlalchemy import func, Index
diff --git a/doc/build/core/custom_types.rst b/doc/build/core/custom_types.rst
index dd93b5bb3..cbcc8c226 100644
--- a/doc/build/core/custom_types.rst
+++ b/doc/build/core/custom_types.rst
@@ -124,7 +124,7 @@ Backend-agnostic GUID Type
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Receives and returns Python uuid() objects.  Uses the PG UUID type
-when using Postgresql, CHAR(32) on other backends, storing them
+when using PostgreSQL, CHAR(32) on other backends, storing them
 in stringified hex format.   Can be modified to store
 binary in CHAR(16) if desired::
 
@@ -135,7 +135,7 @@ binary in CHAR(16) if desired::
     class GUID(TypeDecorator):
         """Platform-independent GUID type.
 
-        Uses Postgresql's UUID type, otherwise uses
+        Uses PostgreSQL's UUID type, otherwise uses
         CHAR(32), storing as stringified hex values.
 
         """
@@ -338,7 +338,7 @@ possible to define SQL-level transformations as well.  The rationale here is whe
 only the relational database contains a particular series of functions that are necessary
 to coerce incoming and outgoing data between an application and persistence format.
 Examples include using database-defined encryption/decryption functions, as well
-as stored procedures that handle geographic data.  The Postgis extension to Postgresql
+as stored procedures that handle geographic data.  The Postgis extension to PostgreSQL
 includes an extensive array of SQL functions that are necessary for coercing
 data into particular formats.
 
@@ -401,7 +401,7 @@ Output::
 
 For an example of subclassing a built in type directly, we subclass
 :class:`.postgresql.BYTEA` to provide a ``PGPString``, which will make use of the
-Postgresql ``pgcrypto`` extension to encrypt/decrypt values
+PostgreSQL ``pgcrypto`` extension to encrypt/decrypt values
 transparently::
 
     from sqlalchemy import create_engine, String, select, func, \
@@ -535,7 +535,7 @@ Using the above type::
 
 Unary operations
 are also possible.  For example, to add an implementation of the
-Postgresql factorial operator, we combine the :class:`.UnaryExpression` construct
+PostgreSQL factorial operator, we combine the :class:`.UnaryExpression` construct
 along with a :class:`.custom_op` to produce the factorial expression::
 
     from sqlalchemy import Integer
diff --git a/doc/build/core/ddl.rst b/doc/build/core/ddl.rst
index 820ba7b84..76692226e 100644
--- a/doc/build/core/ddl.rst
+++ b/doc/build/core/ddl.rst
@@ -51,7 +51,7 @@ The :class:`~.schema.DDL` construct introduced previously also has the
 ability to be invoked conditionally based on inspection of the
 database.  This feature is available using the :meth:`.DDLElement.execute_if`
 method.  For example, if we wanted to create a trigger but only on
-the Postgresql backend, we could invoke this as::
+the PostgreSQL backend, we could invoke this as::
 
     mytable = Table(
         'mytable', metadata,
@@ -87,7 +87,7 @@ of string dialect names::
 The :meth:`.DDLElement.execute_if` method can also work against a callable
 function that will receive the database connection in use.  In the
 example below, we use this to conditionally create a CHECK constraint,
-first looking within the Postgresql catalogs to see if it exists:
+first looking within the PostgreSQL catalogs to see if it exists:
 
 .. sourcecode:: python+sql
 
diff --git a/doc/build/core/defaults.rst b/doc/build/core/defaults.rst
index b0001200c..9fe0a92c0 100644
--- a/doc/build/core/defaults.rst
+++ b/doc/build/core/defaults.rst
@@ -169,7 +169,7 @@ is true:
   well as some MySQL dialects.
 * the dialect does not support the "RETURNING" clause or similar, or the
   ``implicit_returning`` flag is set to ``False`` for the dialect. Dialects
-  which support RETURNING currently include Postgresql, Oracle, Firebird, and
+  which support RETURNING currently include PostgreSQL, Oracle, Firebird, and
   MS-SQL.
 * the statement is a single execution, i.e. only supplies one set of
   parameters and doesn't use "executemany" behavior
@@ -278,7 +278,7 @@ Defining Sequences
 SQLAlchemy represents database sequences using the
 :class:`~sqlalchemy.schema.Sequence` object, which is considered to be a
 special case of "column default". It only has an effect on databases which
-have explicit support for sequences, which currently includes Postgresql,
+have explicit support for sequences, which currently includes PostgreSQL,
 Oracle, and Firebird. The :class:`~sqlalchemy.schema.Sequence` object is
 otherwise ignored.
 
@@ -304,7 +304,7 @@ for the sequence object as well, thus "bundling" the sequence object with its
 parent table.
 
 The :class:`~sqlalchemy.schema.Sequence` object also implements special
-functionality to accommodate Postgresql's SERIAL datatype. The SERIAL type in
+functionality to accommodate PostgreSQL's SERIAL datatype. The SERIAL type in
 PG automatically generates a sequence that is used implicitly during inserts.
 This means that if a :class:`~sqlalchemy.schema.Table` object defines a
 :class:`~sqlalchemy.schema.Sequence` on its primary key column so that it
@@ -343,7 +343,7 @@ sequence, available from the :meth:`.Sequence.next_value` method::
         Column("createdate", DateTime())
     )
 
-The above metadata will generate a CREATE TABLE statement on Postgresql as::
+The above metadata will generate a CREATE TABLE statement on PostgreSQL as::
 
     CREATE TABLE cartitems (
         cart_id INTEGER DEFAULT nextval('cart_id_seq') NOT NULL,
@@ -355,7 +355,7 @@ The above metadata will generate a CREATE TABLE statement on Postgresql as::
 We place the :class:`.Sequence` also as a Python-side default above, that
 is, it is mentioned twice in the :class:`.Column` definition.   Depending
 on the backend in use, this may not be strictly necessary, for example
-on the Postgresql backend the Core will use ``RETURNING`` to access the
+on the PostgreSQL backend the Core will use ``RETURNING`` to access the
 newly generated primary key value in any case.   However, for the best
 compatibility, :class:`.Sequence` was originally intended to be a Python-side
 directive first and foremost so it's probably a good idea to specify it
diff --git a/doc/build/core/engines.rst b/doc/build/core/engines.rst
index 17ec9416c..f429ba561 100644
--- a/doc/build/core/engines.rst
+++ b/doc/build/core/engines.rst
@@ -75,10 +75,10 @@ Examples for common connection styles follow below.  For a full index of
 detailed information on all included dialects as well as links to third-party dialects, see
 :ref:`dialect_toplevel`.
 
-Postgresql
+PostgreSQL
 ----------
 
-The Postgresql dialect uses psycopg2 as the default DBAPI.  pg8000 is
+The PostgreSQL dialect uses psycopg2 as the default DBAPI.  pg8000 is
 also available as a pure-Python substitute::
 
     # default
@@ -90,7 +90,7 @@ also available as a pure-Python substitute::
     # pg8000
     engine = create_engine('postgresql+pg8000://scott:tiger@localhost/mydatabase')
 
-More notes on connecting to Postgresql at :ref:`postgresql_toplevel`.
+More notes on connecting to PostgreSQL at :ref:`postgresql_toplevel`.
 
 MySQL
 -----
diff --git a/doc/build/core/reflection.rst b/doc/build/core/reflection.rst
index f70e3bec6..ca1e3bf20 100644
--- a/doc/build/core/reflection.rst
+++ b/doc/build/core/reflection.rst
@@ -157,7 +157,7 @@ objects returned from reflection cannot be always relied upon to produce the ide
 DDL as the original Python-defined :class:`.Table` objects.   Areas where
 this occurs includes server defaults, column-associated sequences and various
 idosyncrasies regarding constraints and datatypes.   Server side defaults may
-be returned with cast directives (typically Postgresql will include a ``::<type>``
+be returned with cast directives (typically PostgreSQL will include a ``::<type>``
 cast) or different quoting patterns than originally specified.
 
 Another category of limitation includes schema structures for which reflection
diff --git a/doc/build/core/tutorial.rst b/doc/build/core/tutorial.rst
index 453152662..f42f54039 100644
--- a/doc/build/core/tutorial.rst
+++ b/doc/build/core/tutorial.rst
@@ -172,7 +172,7 @@ each table first before creating, so it's safe to call multiple times:
 .. note::
 
     Users familiar with the syntax of CREATE TABLE may notice that the
-    VARCHAR columns were generated without a length; on SQLite and Postgresql,
+    VARCHAR columns were generated without a length; on SQLite and PostgreSQL,
     this is a valid datatype, but on others, it's not allowed. So if running
     this tutorial on one of those databases, and you wish to use SQLAlchemy to
     issue CREATE TABLE, a "length" may be provided to the :class:`~sqlalchemy.types.String` type as
@@ -1722,7 +1722,7 @@ LATERAL correlation is a special sub-category of SQL correlation which
 allows a selectable unit to refer to another selectable unit within a
 single FROM clause.  This is an extremely special use case which, while
 part of the SQL standard, is only known to be supported by recent
-versions of Postgresql.
+versions of PostgreSQL.
 
 Normally, if a SELECT statement refers to
 ``table1 JOIN (some SELECT) AS subquery`` in its FROM clause, the subquery
@@ -1863,7 +1863,7 @@ is the DISTINCT modifier.  A simple DISTINCT clause can be added using the
 
 Most database backends support a system of limiting how many rows
 are returned, and the majority also feature a means of starting to return
-rows after a given "offset".   While common backends like Postgresql,
+rows after a given "offset".   While common backends like PostgreSQL,
 MySQL and SQLite support LIMIT and OFFSET keywords, other backends
 need to refer to more esoteric features such as "window functions"
 and row ids to achieve the same effect.  The :meth:`~.Select.limit`
@@ -2001,7 +2001,7 @@ Multiple Table Updates
 
 .. versionadded:: 0.7.4
 
-The Postgresql, Microsoft SQL Server, and MySQL backends all support UPDATE statements
+The PostgreSQL, Microsoft SQL Server, and MySQL backends all support UPDATE statements
 that refer to multiple tables.   For PG and MSSQL, this is the "UPDATE FROM" syntax,
 which updates one table at a time, but can reference additional tables in an additional
 "FROM" clause that can then be referenced in the WHERE clause directly.   On MySQL,
diff --git a/doc/build/core/type_basics.rst b/doc/build/core/type_basics.rst
index e4f5c74c2..02aa9d2d0 100644
--- a/doc/build/core/type_basics.rst
+++ b/doc/build/core/type_basics.rst
@@ -224,7 +224,7 @@ implemented for that backend::
     )
 
 Where above, the INTEGER and VARCHAR types are ultimately from
-sqlalchemy.types, and INET is specific to the Postgresql dialect.
+sqlalchemy.types, and INET is specific to the PostgreSQL dialect.
 
 Some dialect level types have the same name as the SQL standard type,
 but also provide additional arguments.  For example, MySQL implements
diff --git a/doc/build/dialects/index.rst b/doc/build/dialects/index.rst
index f569cbd38..cb967066a 100644
--- a/doc/build/dialects/index.rst
+++ b/doc/build/dialects/index.rst
@@ -35,7 +35,7 @@ External Dialects
    as external projects.   The rationale here is to keep the base
    SQLAlchemy install and test suite from growing inordinately large.
 
-   The "classic" dialects such as SQLite, MySQL, Postgresql, Oracle,
+   The "classic" dialects such as SQLite, MySQL, PostgreSQL, Oracle,
    SQL Server, and Firebird will remain in the Core for the time being.
 
 .. versionchanged:: 1.0
@@ -49,7 +49,7 @@ Production Ready
 * `ibm_db_sa <http://code.google.com/p/ibm-db/wiki/README>`_ - driver for IBM DB2 and Informix,
   developed jointly by IBM and SQLAlchemy developers.
 * `sqlalchemy-redshift <https://pypi.python.org/pypi/sqlalchemy-redshift>`_ - driver for Amazon Redshift, adapts
-  the existing Postgresql/psycopg2 driver.
+  the existing PostgreSQL/psycopg2 driver.
 * `sqlalchemy_exasol <https://github.com/blue-yonder/sqlalchemy_exasol>`_ - driver for EXASolution.
 * `sqlalchemy-sqlany <https://github.com/sqlanywhere/sqlalchemy-sqlany>`_ - driver for SAP Sybase SQL
   Anywhere, developed by SAP.
diff --git a/doc/build/faq/connections.rst b/doc/build/faq/connections.rst
index 658b4f785..7e763d288 100644
--- a/doc/build/faq/connections.rst
+++ b/doc/build/faq/connections.rst
@@ -63,7 +63,7 @@ this is the default behavior of the Python database API, meaning it
 must be assumed that a transaction is always in progress. The
 connection pool issues ``connection.rollback()`` when a connection is returned.
 This is so that any transactional resources remaining on the connection are
-released. On a database like Postgresql or MSSQL where table resources are
+released. On a database like PostgreSQL or MSSQL where table resources are
 aggressively locked, this is critical so that rows and tables don't remain
 locked within connections that are no longer in use. An application can
 otherwise hang. It's not just for locks, however, and is equally critical on
diff --git a/doc/build/glossary.rst b/doc/build/glossary.rst
index 578656465..40f1ac788 100644
--- a/doc/build/glossary.rst
+++ b/doc/build/glossary.rst
@@ -574,7 +574,7 @@ Glossary
         were created, as well as a way to get at server-generated
         default values in an atomic way.
 
-        An example of RETURNING, idiomatic to Postgresql, looks like::
+        An example of RETURNING, idiomatic to PostgreSQL, looks like::
 
             INSERT INTO user_account (name) VALUES ('new name') RETURNING id, timestamp
 
@@ -585,8 +585,8 @@ Glossary
         or SQL expressions can be placed into RETURNING, not just default-value columns).
 
         The backends that currently support
-        RETURNING or a similar construct are Postgresql, SQL Server, Oracle,
-        and Firebird.    The Postgresql and Firebird implementations are generally
+        RETURNING or a similar construct are PostgreSQL, SQL Server, Oracle,
+        and Firebird.    The PostgreSQL and Firebird implementations are generally
         full featured, whereas the implementations of SQL Server and Oracle
         have caveats. On SQL Server, the clause is known as "OUTPUT INSERTED"
         for INSERT and UPDATE statements and "OUTPUT DELETED" for DELETE statements;
diff --git a/doc/build/orm/join_conditions.rst b/doc/build/orm/join_conditions.rst
index c39b7312e..f40ad23de 100644
--- a/doc/build/orm/join_conditions.rst
+++ b/doc/build/orm/join_conditions.rst
@@ -185,7 +185,7 @@ along with :paramref:`~.relationship.foreign_keys` and :paramref:`~.relationship
 establish such a join.
 
 Below, a class ``HostEntry`` joins to itself, equating the string ``content``
-column to the ``ip_address`` column, which is a Postgresql type called ``INET``.
+column to the ``ip_address`` column, which is a PostgreSQL type called ``INET``.
 We need to use :func:`.cast` in order to cast one side of the join to the
 type of the other::
 
@@ -251,7 +251,7 @@ Using custom operators in join conditions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Another use case for relationships is the use of custom operators, such
-as Postgresql's "is contained within" ``<<`` operator when joining with
+as PostgreSQL's "is contained within" ``<<`` operator when joining with
 types such as :class:`.postgresql.INET` and :class:`.postgresql.CIDR`.
 For custom operators we use the :meth:`.Operators.op` function::
 
diff --git a/doc/build/orm/session_transaction.rst b/doc/build/orm/session_transaction.rst
index 332f1c5f4..ede455223 100644
--- a/doc/build/orm/session_transaction.rst
+++ b/doc/build/orm/session_transaction.rst
@@ -299,7 +299,7 @@ order to affect transaction isolation level, we need to act upon the
 
     :ref:`SQLite Transaction Isolation <sqlite_isolation_level>`
 
-    :ref:`Postgresql Isolation Level <postgresql_isolation_level>`
+    :ref:`PostgreSQL Isolation Level <postgresql_isolation_level>`
 
     :ref:`MySQL Isolation Level <mysql_isolation_level>`
 
diff --git a/doc/build/orm/tutorial.rst b/doc/build/orm/tutorial.rst
index 0a9fc7430..a6eb9d196 100644
--- a/doc/build/orm/tutorial.rst
+++ b/doc/build/orm/tutorial.rst
@@ -224,7 +224,7 @@ the actual ``CREATE TABLE`` statement:
 .. topic:: Minimal Table Descriptions vs. Full Descriptions
 
     Users familiar with the syntax of CREATE TABLE may notice that the
-    VARCHAR columns were generated without a length; on SQLite and Postgresql,
+    VARCHAR columns were generated without a length; on SQLite and PostgreSQL,
     this is a valid datatype, but on others, it's not allowed. So if running
     this tutorial on one of those databases, and you wish to use SQLAlchemy to
     issue CREATE TABLE, a "length" may be provided to the :class:`~sqlalchemy.types.String` type as
diff --git a/doc/build/orm/versioning.rst b/doc/build/orm/versioning.rst
index 35304086d..a2f1635c9 100644
--- a/doc/build/orm/versioning.rst
+++ b/doc/build/orm/versioning.rst
@@ -45,7 +45,7 @@ transaction).
 
     .. seealso::
 
-        `Repeatable Read Isolation Level <http://www.postgresql.org/docs/9.1/static/transaction-iso.html#XACT-REPEATABLE-READ>`_ - Postgresql's implementation of repeatable read, including a description of the error condition.
+        `Repeatable Read Isolation Level <http://www.postgresql.org/docs/9.1/static/transaction-iso.html#XACT-REPEATABLE-READ>`_ - PostgreSQL's implementation of repeatable read, including a description of the error condition.
 
 Simple Version Counting
 -----------------------
@@ -136,10 +136,10 @@ that is generated by the database.  In this case, the database would need
 some means of generating new identifiers when a row is subject to an INSERT
 as well as with an UPDATE.   For the UPDATE case, typically an update trigger
 is needed, unless the database in question supports some other native
-version identifier.  The Postgresql database in particular supports a system
+version identifier.  The PostgreSQL database in particular supports a system
 column called `xmin <http://www.postgresql.org/docs/9.1/static/ddl-system-columns.html>`_
 which provides UPDATE versioning.  We can make use
-of the Postgresql ``xmin`` column to version our ``User``
+of the PostgreSQL ``xmin`` column to version our ``User``
 class as follows::
 
     class User(Base):
@@ -159,7 +159,7 @@ automatically providing the new value of the version id counter.
 
 .. topic:: creating tables that refer to system columns
 
-    In the above scenario, as ``xmin`` is a system column provided by Postgresql,
+    In the above scenario, as ``xmin`` is a system column provided by PostgreSQL,
     we use the ``system=True`` argument to mark it as a system-provided
     column, omitted from the ``CREATE TABLE`` statement.
 
@@ -196,7 +196,7 @@ missed version counters::
 
 It is *strongly recommended* that server side version counters only be used
 when absolutely necessary and only on backends that support :term:`RETURNING`,
-e.g. Postgresql, Oracle, SQL Server (though SQL Server has
+e.g. PostgreSQL, Oracle, SQL Server (though SQL Server has
 `major caveats <http://blogs.msdn.com/b/sqlprogrammability/archive/2008/07/11/update-with-output-clause-triggers-and-sqlmoreresults.aspx>`_ when triggers are used), Firebird.
 
 .. versionadded:: 0.9.0