The tox runner contains a series of target combinations that can run
against various combinations of databases. The test suite can be
-run against SQLite with "backend" tests also running against a Postgresql
+run against SQLite with "backend" tests also running against a PostgreSQL
database::
tox -e py36-sqlite-postgresql
Above will run the tests in the test/sql/test_query.py file (a pretty good
file for basic "does this database work at all?" to start with) against a
-running Postgresql database at the given URL.
+running PostgreSQL database at the given URL.
The py.test frontend can also run tests against multiple kinds of databases
at once - a large subset of tests are marked as "backend" tests, which will
be run against each available backend, and additionally lots of tests are targeted
at specific backends only, which only run if a matching backend is made available.
-For example, to run the test suite against both Postgresql and MySQL at the same time::
+For example, to run the test suite against both PostgreSQL and MySQL at the same time::
py.test -n4 --db postgresql --db mysql
``_reset_exported()`` would corrupt the state of the object. This
method is intended for selectable objects and is called by the ORM
in some cases; an erroneous mapper configuration would could lead the
- ORM to call this on on a :class:`.Table` object.
+ ORM to call this on a :class:`.Table` object.
.. change::
:tags: bug, ext
construct, when the target :class:`.Table` has Python-side defaults.
The :class:`.Select` construct would compile standalone with the
erroneous column present subsequent to compilation of the
- :class:`.Insert`, and the the :class:`.Insert` statement itself would
+ :class:`.Insert`, and the :class:`.Insert` statement itself would
fail on a second compile attempt due to duplicate bound parameters.
.. change::
:tickets: 4208
:versions: 1.2.5, 1.3.0b1
- Fixed bug in Postgresql COLLATE / ARRAY adjustment first introduced
+ Fixed bug in PostgreSQL COLLATE / ARRAY adjustment first introduced
in :ticket:`4006` where new behaviors in Python 3.7 regular expressions
caused the fix to fail.
:tags: bug, postgresql
Added "TRUNCATE" to the list of keywords accepted by the
- Postgresql dialect as an "autocommit"-triggering keyword.
+ PostgreSQL dialect as an "autocommit"-triggering keyword.
Pull request courtesy Jacob Hayes.
.. change::
:versions: 1.2.0b3
Fixed bug in :obj:`.array_agg` function where passing an argument
- that is already of type :class:`.ARRAY`, such as a Postgresql
+ that is already of type :class:`.ARRAY`, such as a PostgreSQL
:obj:`.postgresql.array` construct, would produce a ``ValueError``, due
to the function attempting to nest the arrays.
:tickets: 4074
:versions: 1.2.0b3
- Fixed bug in Postgresql :meth:`.postgresql.dml.Insert.on_conflict_do_update`
+ Fixed bug in PostgreSQL :meth:`.postgresql.dml.Insert.on_conflict_do_update`
which would prevent the insert statement from being used as a CTE,
e.g. via :meth:`.Insert.cte`, within another statement.
:tickets: 4005
:versions: 1.2.0b1
- Continuing with the fix that correctly handles Postgresql
+ Continuing with the fix that correctly handles PostgreSQL
version string "10devel" released in 1.1.8, an additional regexp
bump to handle version strings of the form "10beta1". While
- Postgresql now offers better ways to get this information, we
+ PostgreSQL now offers better ways to get this information, we
are sticking w/ the regexp at least through 1.1.x for the least
- amount of risk to compatibility w/ older or alternate Postgresql
+ amount of risk to compatibility w/ older or alternate PostgreSQL
databases.
.. change:: 4006
Changed the mechanics of :class:`.ResultProxy` to unconditionally
delay the "autoclose" step until the :class:`.Connection` is done
- with the object; in the case where Postgresql ON CONFLICT with
+ with the object; in the case where PostgreSQL ON CONFLICT with
RETURNING returns no rows, autoclose was occurring in this previously
non-existent use case, causing the usual autocommit behavior that
occurs unconditionally upon INSERT/UPDATE/DELETE to fail.
:tags: bug, postgresql
:versions: 1.2.0b1
- Added support for parsing the Postgresql version string for
+ Added support for parsing the PostgreSQL version string for
a development version like "PostgreSQL 10devel". Pull request
courtesy Sean McCully.
:tickets: 3804
Added regular expressions for the "IMPORT FOREIGN SCHEMA",
- "REFRESH MATERIALIZED VIEW" Postgresql statements so that they
+ "REFRESH MATERIALIZED VIEW" PostgreSQL statements so that they
autocommit when invoked via a connection or engine without
an explicit transaction. Pull requests courtesy Frazer McLean
and Paweł Stiasny.
:tags: bug, postgresql
:tickets: 3900
- Fixed bug in Postgresql :class:`.ExcludeConstraint` where the
+ Fixed bug in PostgreSQL :class:`.ExcludeConstraint` where the
"whereclause" and "using" parameters would not be copied during an
operation like :meth:`.Table.tometadata`.
pymysql dialects. This feature is available via the
:paramref:`.Connection.execution_options.stream_results` flag as well
as the ``server_side_cursors=True`` dialect argument in the
- same way that it has been for psycopg2 on Postgresql. Pull request
+ same way that it has been for psycopg2 on PostgreSQL. Pull request
courtesy Roman Podoliaka.
.. change::
:tags: bug, postgresql
:tickets: 3835
- Postgresql table reflection will ensure that the
+ PostgreSQL table reflection will ensure that the
:paramref:`.Column.autoincrement` flag is set to False when reflecting
a primary key column that is not of an :class:`.Integer` datatype,
even if the default is related to an integer-generating sequence.
integer values, such as strings, also changed in behavior such that the
string value ``"0"`` would be interpreted as "true", but only on backends
that don't have a native boolean datatype - on "native boolean" backends
- like Postgresql, the string value ``"0"`` is passed directly to the driver
+ like PostgreSQL, the string value ``"0"`` is passed directly to the driver
and is interpreted as "false". This is an inconsistency that did not occur
- with the previous implementation.It should be noted that passing strings or
+ with the previous implementation. It should be noted that passing strings or
any other value outside of ``None``, ``True``, ``False``, ``1``, ``0`` to
the :class:`.Boolean` datatype is **not supported** and version 1.2 will
raise an error for this scenario (or possibly just emit a warning, TBD).
is disabled entirely.
When the query is being bundled into a subquery for the purposes of
-joined eager loading, the "augment column list" rules are are necessarily
+joined eager loading, the "augment column list" rules are necessarily
more aggressive so that the ORDER BY can still be satisfied, so this case
remains unchanged.
The ``delete`` cascade indicates that when a "parent" object
is marked for deletion, its related "child" objects should also be marked
-for deletion. If for example we we have a relationship ``User.addresses``
+for deletion. If for example we have a relationship ``User.addresses``
with ``delete`` cascade configured::
class User(Base):
make sure SQLAlchemy can "pre-execute" the default, which means it has to be an
explicit SQL expression.
-.. note:: This section will will illustrate multiple recipes involving
+.. note:: This section will illustrate multiple recipes involving
datetime values for MySQL and SQLite, since the datetime datatypes on these
two backends have additional idiosyncratic requirements that are useful to
illustrate. Keep in mind however that SQLite and MySQL require an explicit
The :class:`.Session` also features an older legacy mode of use called
**autocommit mode**, where a transaction is not started implicitly, and unless
-the the :meth:`.Session.begin` method is invoked, the :class:`.Session` will
+the :meth:`.Session.begin` method is invoked, the :class:`.Session` will
perform each database operation on a new connection checked out from the
connection pool, which is then released back to the pool immediately
after the operation completes. This refers to
via the nature of the ``BEGIN`` statement used. The three varieties
are "deferred", "immediate", and "exclusive", as described at
`BEGIN TRANSACTION <http://sqlite.org/lang_transaction.html>`_. A straight
-``BEGIN`` statement uses the "deferred" mode, where the the database file is
+``BEGIN`` statement uses the "deferred" mode, where the database file is
not locked until the first read or write operation, and read access remains
open to other transactions until the first write operation. But again,
it is critical to note that the pysqlite driver interferes with this behavior
Index operations return an expression object whose type defaults to
:class:`.JSON` by default, so that further JSON-oriented instructions
may be called upon the result type. Note that there are backend-specific
- idiosyncracies here, including that the Postgresql database does not generally
+ idiosyncracies here, including that the PostgreSQL database does not generally
compare a "json" to a "json" structure without type casts. These idiosyncracies
- can be accommodated in a backend-neutral way by by making explicit use
+ can be accommodated in a backend-neutral way by making explicit use
of the :func:`.cast` and :func:`.type_coerce` constructs.
Comparison of specific index elements of a :class:`.JSON` object
- to other objects work best if the **left hand side is CAST to a string**
- and the **right hand side is rendered as a json string**; a future SQLAlchemy
+ to other objects works best if the **left hand side is CAST to a string**
+ and the **right hand side is rendered as a JSON string**; a future SQLAlchemy
feature such as a generic "astext" modifier may simplify this at some point:
* **Compare an element of a JSON structure to a string**::
make_option("--nomemory", action="store_true", dest="nomemory",
help="Don't run memory profiling tests")
make_option("--postgresql-templatedb", type="string",
- help="name of template database to use for Postgresql "
+ help="name of template database to use for PostgreSQL "
"CREATE DATABASE (defaults to current database)")
make_option("--low-connections", action="store_true",
dest="low_connections",
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
