From 5503028d8cc404bb28fd5760f5ba6c27cfc37ae2 Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Mon, 13 Jul 2009 02:04:54 +0000 Subject: [PATCH] changed reference to PostgreSQL in docs. --- CHANGES | 8 ++++---- README.unittests | 4 ++-- doc/build/dbengine.rst | 4 ++-- doc/build/mappers.rst | 2 +- doc/build/metadata.rst | 4 ++-- doc/build/ormtutorial.rst | 2 +- lib/sqlalchemy/databases/postgres.py | 10 +++++----- lib/sqlalchemy/engine/__init__.py | 2 +- lib/sqlalchemy/orm/__init__.py | 2 +- lib/sqlalchemy/schema.py | 2 +- test/engine/test_transaction.py | 4 ++-- test/sql/test_select.py | 2 +- 12 files changed, 23 insertions(+), 23 deletions(-) diff --git a/CHANGES b/CHANGES index ffe4c41fc3..2ea185a91a 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 bfc31e28fb..99edfcacec 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 362526943d..4814bb85e8 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 `_ +* PostgreSQL: `psycopg2 `_ * SQLite: `sqlite3 `_ (included in Python 2.5 or greater) `pysqlite `_ * MySQL: `MySQLDB `_ * Oracle: `cx_Oracle `_ diff --git a/doc/build/mappers.rst b/doc/build/mappers.rst index 2431cebce2..20a23b0c4c 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 b4da3c4afa..f79c637ee0 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 423c235d24..acdbba149e 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 4fc79921ba..154d971e35 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 b0f4465985..bb2b1b5be4 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 a80d17642b..4c4ec8513c 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 2ec359f381..5d31543d83 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 7d40adf6d0..6698259a45 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 1d9e531de3..f70492fb31 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 -- 2.47.2