- 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.
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/>`_
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()``).
* 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:
()
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))
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
: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
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.
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`
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'
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
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
