Commits

Mike Bayer committed 941a296

changed reference to PostgreSQL in docs.

Comments (0)

Files changed (12)

 - 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
 - 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
     - 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]
 
     - 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]
 
 
 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.

doc/build/dbengine.rst

 
 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/>`_

doc/build/mappers.rst

     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()``).
 

doc/build/metadata.rst

 
 * 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
 
 
 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:
 

doc/build/ormtutorial.rst

     ()
     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))
 

lib/sqlalchemy/databases/postgres.py

 
 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 
 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
 "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.
 
 Transactions
 ------------
 
-The Postgres dialect fully supports SAVEPOINT and two-phase commit operations.
+The PostgreSQL dialect fully supports SAVEPOINT and two-phase commit operations.
 
 
 """
 
     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
 

lib/sqlalchemy/engine/__init__.py

     :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

lib/sqlalchemy/orm/__init__.py

       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.

lib/sqlalchemy/schema.py

             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`

test/engine/test_transaction.py

         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)
 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'

test/sql/test_select.py

             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
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.