changed reference to PostgreSQL in docs.rel_0_5_5

12 files changed, 23 insertions, 23 deletions

diff --git a/CHANGES b/CHANGES
index ffe4c41fc..2ea185a91 100644
--- a/CHANGES
+++ b/CHANGES
@@ -109,7 +109,7 @@ CHANGES
 - postgres
     - Deprecated the hardcoded TIMESTAMP function, which when
       used as func.TIMESTAMP(value) would render "TIMESTAMP value".
-      This breaks on some platforms as Postgres doesn't allow
+      This breaks on some platforms as PostgreSQL doesn't allow
       bind parameters to be used in this context.  The hard-coded
       uppercase is also inappropriate and there's lots of other
       PG casts that we'd need to support.  So instead, use
@@ -602,7 +602,7 @@ CHANGES
 - sql
     - Improved the methodology to handling percent signs in column
       names from [ticket:1256].  Added more tests.  MySQL and
-      Postgres dialects still do not issue correct CREATE TABLE
+      PostgreSQL dialects still do not issue correct CREATE TABLE
       statements for identifiers with percent signs in them.
       
 - schema
@@ -985,7 +985,7 @@ CHANGES
     - Calling alias.execute() in conjunction with
       server_side_cursors won't raise AttributeError.
 
-    - Added Index reflection support to Postgres, using a great
+    - Added Index reflection support to PostgreSQL, using a great
       patch we long neglected, submitted by Ken
       Kuhlman. [ticket:714]
 
@@ -1606,7 +1606,7 @@ CHANGES
     - simple label names in ORDER BY expressions render as
       themselves, and not as a re-statement of their corresponding
       expression.  This feature is currently enabled only for
-      SQLite, MySQL, and Postgres.  It can be enabled on other
+      SQLite, MySQL, and PostgreSQL.  It can be enabled on other
       dialects as each is shown to support this
       behavior. [ticket:1068]
 
diff --git a/README.unittests b/README.unittests
index bfc31e28f..99edfcace 100644
--- a/README.unittests
+++ b/README.unittests
@@ -159,10 +159,10 @@ IRC!
 
 TIPS
 ----
-Postgres: The tests require an 'alt_schema' and 'alt_schema_2' to be present in
+PostgreSQL: The tests require an 'alt_schema' and 'alt_schema_2' to be present in
 the testing database.
 
-Postgres: When running the tests on postgres, postgres can get slower and
+PostgreSQL: When running the tests on postgres, postgres can get slower and
 slower each time you run the tests.  This seems to be related to the constant
 creation/dropping of tables.  Running a "VACUUM FULL" on the database will
 speed it up again.
diff --git a/doc/build/dbengine.rst b/doc/build/dbengine.rst
index 362526943..4814bb85e 100644
--- a/doc/build/dbengine.rst
+++ b/doc/build/dbengine.rst
@@ -52,11 +52,11 @@ The ``Engine`` and ``Connection`` can do a lot more than what we illustrated abo
 
 Supported Databases 
 ====================
-Recall that the ``Dialect`` is used to describe how to talk to a specific kind of database.  Dialects are included with SQLAlchemy for SQLite, Postgres, MySQL, MS-SQL, Firebird, Informix, and Oracle; these can each be seen as a Python module present in the :mod:``~sqlalchemy.databases`` package.  Each dialect requires the appropriate DBAPI drivers to be installed separately.
+Recall that the ``Dialect`` is used to describe how to talk to a specific kind of database.  Dialects are included with SQLAlchemy for SQLite, PostgreSQL, MySQL, MS-SQL, Firebird, Informix, and Oracle; these can each be seen as a Python module present in the :mod:``~sqlalchemy.databases`` package.  Each dialect requires the appropriate DBAPI drivers to be installed separately.
 
 Downloads for each DBAPI at the time of this writing are as follows:
 
-* Postgres:  `psycopg2 <http://www.initd.org/tracker/psycopg/wiki/PsycopgTwo>`_
+* PostgreSQL:  `psycopg2 <http://www.initd.org/tracker/psycopg/wiki/PsycopgTwo>`_
 * SQLite:  `sqlite3 <http://www.python.org/doc/2.5.2/lib/module-sqlite3.html>`_ (included in Python 2.5 or greater) `pysqlite <http://initd.org/tracker/pysqlite>`_
 * MySQL:   `MySQLDB <http://sourceforge.net/projects/mysql-python>`_
 * Oracle:  `cx_Oracle <http://cx-oracle.sourceforge.net/>`_
diff --git a/doc/build/mappers.rst b/doc/build/mappers.rst
index 2431cebce..20a23b0c4 100644
--- a/doc/build/mappers.rst
+++ b/doc/build/mappers.rst
@@ -1326,7 +1326,7 @@ Or::
     widget_id     name        favorite_entry_id             entry_id      name      widget_id
        1       'somewidget'          5                         5       'someentry'     1
 
-In the first case, a row points to itself.  Technically, a database that uses sequences such as Postgres or Oracle can INSERT the row at once using a previously generated value, but databases which rely upon autoincrement-style primary key identifiers cannot.  The ``relation()`` always assumes a "parent/child" model of row population during flush, so unless you are populating the primary key/foreign key columns directly, ``relation()`` needs to use two statements.
+In the first case, a row points to itself.  Technically, a database that uses sequences such as PostgreSQL or Oracle can INSERT the row at once using a previously generated value, but databases which rely upon autoincrement-style primary key identifiers cannot.  The ``relation()`` always assumes a "parent/child" model of row population during flush, so unless you are populating the primary key/foreign key columns directly, ``relation()`` needs to use two statements.
 
 In the second case, the "widget" row must be inserted before any referring "entry" rows, but then the "favorite_entry_id" column of that "widget" row cannot be set until the "entry" rows have been generated.  In this case, it's typically impossible to insert the "widget" and "entry" rows using just two INSERT statements; an UPDATE must be performed in order to keep foreign key constraints fulfilled.   The exception is if the foreign keys are configured as "deferred until commit" (a feature some databases support) and if the identifiers were populated manually (again essentially bypassing ``relation()``).
 
diff --git a/doc/build/metadata.rst b/doc/build/metadata.rst
index b4da3c4af..f79c637ee 100644
--- a/doc/build/metadata.rst
+++ b/doc/build/metadata.rst
@@ -390,7 +390,7 @@ The above SQL functions are usually executed "inline" with the INSERT or UPDATE
 
 * the column is a primary key column
 
-* the database dialect does not support a usable ``cursor.lastrowid`` accessor (or equivalent); this currently includes Postgres, Oracle, and Firebird.
+* the database dialect does not support a usable ``cursor.lastrowid`` accessor (or equivalent); this currently includes PostgreSQL, Oracle, and Firebird.
 
 * the statement is a single execution, i.e. only supplies one set of parameters and doesn't use "executemany" behavior
 
@@ -450,7 +450,7 @@ The ``Sequence`` object works a lot like the ``default`` keyword on ``Column``,
 
 When the ``Sequence`` is associated with a table, CREATE and DROP statements issued for that table will also issue CREATE/DROP for the sequence object as well, thus "bundling" the sequence object with its parent table.
 
-The flag ``optional=True`` on ``Sequence`` will produce a sequence that is only used on databases which have no "autoincrementing" capability.  For example, Postgres supports primary key generation using the SERIAL keyword, whereas Oracle has no such capability.  Therefore, a ``Sequence`` placed on a primary key column with ``optional=True`` will only be used with an Oracle backend but not Postgres.
+The flag ``optional=True`` on ``Sequence`` will produce a sequence that is only used on databases which have no "autoincrementing" capability.  For example, PostgreSQL supports primary key generation using the SERIAL keyword, whereas Oracle has no such capability.  Therefore, a ``Sequence`` placed on a primary key column with ``optional=True`` will only be used with an Oracle backend but not PostgreSQL.
 
 A sequence can also be executed standalone, using an ``Engine`` or ``Connection``, returning its next value in a database-independent fashion:
 
diff --git a/doc/build/ormtutorial.rst b/doc/build/ormtutorial.rst
index 423c235d2..acdbba149 100644
--- a/doc/build/ormtutorial.rst
+++ b/doc/build/ormtutorial.rst
@@ -56,7 +56,7 @@ Next, we can issue CREATE TABLE statements derived from our table metadata, by c
     ()
     COMMIT
 
-Users familiar with the syntax of CREATE TABLE may notice that the VARCHAR columns were generated without a length; on SQLite, this is a valid datatype, but on most databases it's not allowed.  So if running this tutorial on a database such as Postgres or MySQL, and you wish to use SQLAlchemy to generate the tables, a "length" may be provided to the ``String`` type as below::
+Users familiar with the syntax of CREATE TABLE may notice that the VARCHAR columns were generated without a length; on SQLite, this is a valid datatype, but on most databases it's not allowed.  So if running this tutorial on a database such as PostgreSQL or MySQL, and you wish to use SQLAlchemy to generate the tables, a "length" may be provided to the ``String`` type as below::
 
     Column('name', String(50))
 
diff --git a/lib/sqlalchemy/databases/postgres.py b/lib/sqlalchemy/databases/postgres.py
index 4fc79921b..154d971e3 100644
--- a/lib/sqlalchemy/databases/postgres.py
+++ b/lib/sqlalchemy/databases/postgres.py
@@ -20,7 +20,7 @@ Connecting
 
 URLs are of the form `postgres://user:password@host:port/dbname[?key=value&key=value...]`.
 
-Postgres-specific keyword arguments which are accepted by :func:`~sqlalchemy.create_engine()` are:
+PostgreSQL-specific keyword arguments which are accepted by :func:`~sqlalchemy.create_engine()` are:
 
 * *server_side_cursors* - Enable the usage of "server side cursors" for SQL statements which support
   this feature.  What this essentially means from a psycopg2 point of view is that the cursor is 
@@ -33,7 +33,7 @@ Postgres-specific keyword arguments which are accepted by :func:`~sqlalchemy.cre
 Sequences/SERIAL
 ----------------
 
-Postgres supports sequences, and SQLAlchemy uses these as the default means of creating
+PostgreSQL supports sequences, and SQLAlchemy uses these as the default means of creating
 new primary key values for integer-based primary key columns.   When creating tables, 
 SQLAlchemy will issue the ``SERIAL`` datatype for integer-based primary key columns, 
 which generates a sequence corresponding to the column and associated with it based on
@@ -53,7 +53,7 @@ that when an :func:`~sqlalchemy.sql.expression.insert()` construct is executed u
 "executemany" semantics, the sequence is not pre-executed and normal PG SERIAL behavior
 is used.
 
-Postgres 8.3 supports an ``INSERT...RETURNING`` syntax which SQLAlchemy supports 
+PostgreSQL 8.3 supports an ``INSERT...RETURNING`` syntax which SQLAlchemy supports 
 as well.  A future release of SQLA will use this feature by default in lieu of 
 sequence pre-execution in order to retrieve new primary key values, when available.
 
@@ -84,7 +84,7 @@ option to the Index constructor::
 Transactions
 ------------
 
-The Postgres dialect fully supports SAVEPOINT and two-phase commit operations.
+The PostgreSQL dialect fully supports SAVEPOINT and two-phase commit operations.
 
 
 """
@@ -411,7 +411,7 @@ class PGDialect(default.DefaultDialect):
 
     def last_inserted_ids(self):
         if self.context.last_inserted_ids is None:
-            raise exc.InvalidRequestError("no INSERT executed, or can't use cursor.lastrowid without Postgres OIDs enabled")
+            raise exc.InvalidRequestError("no INSERT executed, or can't use cursor.lastrowid without PostgreSQL OIDs enabled")
         else:
             return self.context.last_inserted_ids
 
diff --git a/lib/sqlalchemy/engine/__init__.py b/lib/sqlalchemy/engine/__init__.py
index b0f446598..bb2b1b5be 100644
--- a/lib/sqlalchemy/engine/__init__.py
+++ b/lib/sqlalchemy/engine/__init__.py
@@ -173,7 +173,7 @@ def create_engine(*args, **kwargs):
     :param module=None: used by database implementations which
         support multiple DBAPI modules, this is a reference to a DBAPI2
         module to be used instead of the engine's default module. For
-        Postgres, the default is psycopg2. For Oracle, it's cx_Oracle.
+        PostgreSQL, the default is psycopg2. For Oracle, it's cx_Oracle.
 
     :param pool=None: an already-constructed instance of
         :class:`~sqlalchemy.pool.Pool`, such as a
diff --git a/lib/sqlalchemy/orm/__init__.py b/lib/sqlalchemy/orm/__init__.py
index a80d17642..4c4ec8513 100644
--- a/lib/sqlalchemy/orm/__init__.py
+++ b/lib/sqlalchemy/orm/__init__.py
@@ -338,7 +338,7 @@ def relation(argument, secondary=None, **kwargs):
       the foreign key in the database, and that the database will
       handle propagation of an UPDATE from a source column to
       dependent rows.  Note that with databases which enforce
-      referential integrity (i.e. Postgres, MySQL with InnoDB tables),
+      referential integrity (i.e. PostgreSQL, MySQL with InnoDB tables),
       ON UPDATE CASCADE is required for this operation.  The
       relation() will update the value of the attribute on related
       items which are locally present in the session during a flush.
diff --git a/lib/sqlalchemy/schema.py b/lib/sqlalchemy/schema.py
index 2ec359f38..5d31543d8 100644
--- a/lib/sqlalchemy/schema.py
+++ b/lib/sqlalchemy/schema.py
@@ -472,7 +472,7 @@ class Column(SchemaItem, expression.ColumnClause):
             or :meth:`create_all()`.  The flag has no relevance at any
             other time.
           * The database supports autoincrementing behavior, such as 
-            Postgres or MySQL, and this behavior can be disabled (which does
+            PostgreSQL or MySQL, and this behavior can be disabled (which does
             not include SQLite).
 
         :param default: A scalar, Python callable, or :class:`~sqlalchemy.sql.expression.ClauseElement`
diff --git a/test/engine/test_transaction.py b/test/engine/test_transaction.py
index 7d40adf6d..6698259a4 100644
--- a/test/engine/test_transaction.py
+++ b/test/engine/test_transaction.py
@@ -356,7 +356,7 @@ class AutoRollbackTest(TestBase):
         conn1.close()
 
         # without auto-rollback in the connection pool's return() logic, this
-        # deadlocks in Postgres, because conn1 is returned to the pool but
+        # deadlocks in PostgreSQL, because conn1 is returned to the pool but
         # still has a lock on "deadlock_users".
         # comment out the rollback in pool/ConnectionFairy._close() to see !
         users.drop(conn2)
@@ -366,7 +366,7 @@ foo = None
 class ExplicitAutoCommitTest(TestBase):
     """test the 'autocommit' flag on select() and text() objects.
 
-    Requires Postgres so that we may define a custom function which modifies the database.
+    Requires PostgreSQL so that we may define a custom function which modifies the database.
     """
 
     __only_on__ = 'postgres'
diff --git a/test/sql/test_select.py b/test/sql/test_select.py
index 1d9e531de..f70492fb3 100644
--- a/test/sql/test_select.py
+++ b/test/sql/test_select.py
@@ -1302,7 +1302,7 @@ UNION SELECT mytable.myid FROM mytable WHERE mytable.myid = :myid_2)")
             else:
                 eq_(str(sel), "SELECT casttest.id, casttest.v1, casttest.v2, casttest.ts, CAST(casttest.v1 AS NUMERIC(10, 2)) AS anon_1 \nFROM casttest")
 
-        # first test with Postgres engine
+        # first test with PostgreSQL engine
         check_results(postgres.dialect(), ['NUMERIC(10, 2)', 'NUMERIC(12, 9)', 'DATE', 'TEXT', 'VARCHAR(20)'], '%(param_1)s')
 
         # then the Oracle engine