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
- 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.
:versions: 1.2.3
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.
:tags: bug, postgresql
:tickets: 4229
- Fixed bug where the special "not equals" operator for the Postgresql
+ Fixed bug where the special "not equals" operator for the PostgreSQL
"range" datatypes such as DATERANGE would fail to render "IS NOT NULL" when
compared to the Python ``None`` value.
Fixed issue where the compilation of an INSERT statement with the
"literal_binds" option that also uses an explicit sequence and "inline"
- generation, as on Postgresql and Oracle, would fail to accommodate the
+ generation, as on PostgreSQL and Oracle, would fail to accommodate the
extra keyword argument within the sequence processing routine.
.. change::
.. change::
:tags: feature, postgresql
- Added support for "PARTITION BY" in Postgresql table definitions,
+ Added support for "PARTITION BY" in PostgreSQL table definitions,
using "postgresql_partition_by". Pull request courtesy
Vsevolod Solovyov.
:tags: enhancement, sql
:tickets: 959
- Implemented "DELETE..FROM" syntax for Postgresql, MySQL, MS SQL Server
+ Implemented "DELETE..FROM" syntax for PostgreSQL, MySQL, MS SQL Server
(as well as within the unsupported Sybase dialect) in a manner similar
to how "UPDATE..FROM" works. A DELETE statement that refers to more than
one table will switch into "multi-table" mode and render the appropriate
:class:`.Boolean` types, which now extend a common mixin
:class:`.Emulated` that indicates a type that provides Python-side
emulation of a DB native type, switching out to the DB native type when a
- supporting backend is in use. The Postgresql :class:`.INTERVAL` type
+ supporting backend is in use. The PostgreSQL :class:`.INTERVAL` type
when used directly will now include the correct type coercion rules for
SQL expressions that also take effect for :class:`.sqltypes.Interval`
(such as adding a date to an interval yields a datetime).
each other will produce parentheses between them. This suits the
stated operator precedence of databases like Oracle, MySQL and others
which place all of these operators as equal precedence, as well as
- Postgresql as of 9.5 which has also flattened its operator precendence.
+ PostgreSQL as of 9.5 which has also flattened its operator precendence.
.. seealso::
signs mostly associated with the :obj:`.literal_column` construct
as well as operators like :meth:`.ColumnOperators.contains` now
occurs based on the stated paramstyle of the DBAPI in use; for
- percent-sensitive paramstyles as are common with the Postgresql
+ percent-sensitive paramstyles as are common with the PostgreSQL
and MySQL drivers the doubling will occur, for others like that
of SQLite it will not. This allows more database-agnostic use
of the :obj:`.literal_column` construct to be possible.
:tickets: 3959
Added support for all possible "fields" identifiers when reflecting the
- Postgresql ``INTERVAL`` datatype, e.g. "YEAR", "MONTH", "DAY TO
+ PostgreSQL ``INTERVAL`` datatype, e.g. "YEAR", "MONTH", "DAY TO
MINUTE", etc.. In addition, the :class:`.postgresql.INTERVAL`
datatype itself now includes a new parameter
:paramref:`.postgresql.INTERVAL.fields` where these qualifiers can be
as part of DDL on table creation, either inline or via an appropriate
ALTER statement, and are also reflected back within table reflection,
as well as via the :class:`.Inspector`. Supported backends currently
- include MySQL, Postgresql, and Oracle. Many thanks to Frazer McLean
+ include MySQL, PostgreSQL, and Oracle. Many thanks to Frazer McLean
for a large amount of effort on this.
.. seealso::
into a parenthesized expression. Using :class:`.Alias` in this way
is not yet a fully supported API, however it applies to some end-user
recipes and may have a more prominent role in support of some
- future Postgresql features.
+ future PostgreSQL features.
.. change:: 3366
:tags: bug, orm
means the query renders with two FOR UPDATE clauses; note that on some
backends such as Oracle, FOR UPDATE clauses on subqueries are silently
ignored since they are unnecessary. Additionally, in the case of the "OF"
- clause used primarily with Postgresql, the FOR UPDATE is rendered only on
+ clause used primarily with PostgreSQL, the FOR UPDATE is rendered only on
the inner subquery when this is used so that the selectable can be targeted
to the table within the SELECT statement.
:tags: feature, postgresql
:tickets: 4237
- Added rudimental support for reflection of Postgresql
+ Added rudimental support for reflection of PostgreSQL
partitioned tables, e.g. that relkind='p' is added to reflection
queries that return table information.
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.
* Because the query only fetches for a given list of primary key identifiers,
"selectin" loading is potentially compatible with :meth:`.Query.yield_per` to
operate on chunks of a SELECT result at a time, provided that the
- database driver allows for multiple, simultaneous cursors (SQlite, Postgresql;
+ database driver allows for multiple, simultaneous cursors (SQlite, PostgreSQL;
**not** MySQL drivers or SQL Server ODBC drivers). Neither joined eager
loading nor subquery eager loading are compatible with :meth:`.Query.yield_per`.
for composite primary keys depends on the database's ability to use
tuples with IN, e.g.
``(table.column_one, table_column_two) IN ((?, ?), (?, ?) (?, ?))``.
-Currently, Postgresql and MySQL are known to be compatible with this syntax,
+Currently, PostgreSQL and MySQL are known to be compatible with this syntax,
SQLite is not.
.. seealso::
SELECT NULL IN (SELECT 1 WHERE 1 != 1)
With the above test, we see that the databases themselves can't agree on
-the answer. Postgresql, considered by most to be the most "correct" database,
+the answer. PostgreSQL, considered by most to be the most "correct" database,
returns False; because even though "NULL" represents "unknown", the "empty set"
means nothing is present, including all unknown values. On the
other hand, MySQL and MariaDB return NULL for the above expression, defaulting
to invoke either approach, that is, the "static" ``1 != 1`` comparison or the
"dynamic" ``expr != expr`` comparison. The default has been **changed**
to be the "static" comparison, since this agrees with the behavior that
-Postgresql would have in any case and this is also what the vast majority
+PostgreSQL would have in any case and this is also what the vast majority
of users prefer. This will **change the result** of a query that is comparing
a null expression to the empty set, particularly one that is querying
for the negation ``where(~null_expr.in_([]))``, since this now evaluates to true
the comments are included. The table comment is also available independently
using the :meth:`.Inspector.get_table_comment` method.
-Current backend support includes MySQL, Postgresql, and Oracle.
+Current backend support includes MySQL, PostgreSQL, and Oracle.
:ticket:`1546`
The :class:`.Delete` construct now supports multiple-table criteria,
implemented for those backends which support it, currently these are
-Postgresql, MySQL and Microsoft SQL Server (support is also added to the
+PostgreSQL, MySQL and Microsoft SQL Server (support is also added to the
currently non-working Sybase dialect). The feature works in the same
was as that of multiple-table criteria for UPDATE, first introduced in
the 0.7 and 0.8 series.
where(addresses.c.email_address.startswith('ed%'))
conn.execute(stmt)
-The resulting SQL from the above statement on a Postgresql backend
+The resulting SQL from the above statement on a PostgreSQL backend
would render as::
DELETE FROM users USING addresses
This parameter when set to ``True`` will automatically escape all occurrences
of ``%``, ``_`` with an escape character, which defaults to a forwards slash ``/``;
occurrences of the escape character itself are also escaped. The forwards slash
-is used to avoid conflicts with settings like Postgresql's
-``standard_confirming_strings``, whose default value changed as of Postgresql
+is used to avoid conflicts with settings like PostgreSQL's
+``standard_confirming_strings``, whose default value changed as of PostgreSQL
9.1, and MySQL's ``NO_BACKSLASH_ESCAPES`` settings. The existing "escape" parameter
can now be used to change the autoescape character, if desired.
DateTime()
As most user-defined operators tend to be "comparison" operators, often
-one of the many special operators defined by Postgresql, the
+one of the many special operators defined by PostgreSQL, the
:paramref:`.Operators.op.is_comparison` flag has been repaired to follow
its documented behavior of allowing the return type to be :class:`.Boolean`
in all cases, including for :class:`.ARRAY` and :class:`.JSON`::
Support for fields specification in INTERVAL, including full reflection
-----------------------------------------------------------------------
-The "fields" specifier in Postgresql's INTERVAL datatype allows specification
+The "fields" specifier in PostgreSQL's INTERVAL datatype allows specification
of which fields of the interval to store, including such values as "YEAR",
"MONTH", "YEAR TO MONTH", etc. The :class:`.postgresql.INTERVAL` datatype
now allows these values to be specified::
directly from the identity map. However, as with most querying features,
the feature's implementation became more complex as a result of advanced
scenarios regarding polymorphic loading. If problems are encountered,
-users should report a bug, however the change also incldues a flag
-:paramref:`.relationship.omit_join` which can be set to False on the
+users should report a bug, however the change also includes a flag
+:paramref:`.relationship.omit_join` which can be set to ``False`` on the
:func:`.relationship` to disable the optimization.
) AS subq LEFT OUTER JOIN b ON subq.a_id=b.a_id FOR UPDATE
However, MySQL due to https://bugs.mysql.com/bug.php?id=90693 does not lock
-the rows inside the subquery, unlike that of Postgresql and other databases.
+the rows inside the subquery, unlike that of PostgreSQL and other databases.
So the above query now renders as::
SELECT subq.a_id, subq.a_data, b_alias.id, b_alias.data FROM (
On the Oracle dialect, the inner "FOR UPDATE" is not rendered as Oracle does
not support this syntax and the dialect skips any "FOR UPDATE" that is against
-a subquery; it isn't necessary in any case since Oracle, like Postgresql,
+a subquery; it isn't necessary in any case since Oracle, like PostgreSQL,
correctly locks all elements of the returned row.
When using the :paramref:`.Query.with_for_update.of` modifier, typically on
-Postgresql, the outer "FOR UPDATE" is omitted, and the OF is now rendered
+PostgreSQL, the outer "FOR UPDATE" is omitted, and the OF is now rendered
on the inside; previously, the OF target would not be converted to accommodate
for the subquery correctly. So
given::
SELECT a.id AS a_id, a.data AS a_data FROM a LIMIT 5 FOR UPDATE OF a
) AS subq LEFT OUTER JOIN b ON subq.a_id=b.a_id
-The above form should be helpful on Postgresql additionally since Postgresql
+The above form should be helpful on PostgreSQL additionally since PostgreSQL
will not allow the FOR UPDATE clause to be rendered after the LEFT OUTER JOIN
target.
The "expanding IN" feature introduced in version 1.2 at :ref:`change_3953` now
supports empty lists passed to the :meth:`.ColumnOperators.in_` operator. The implementation
for an empty list will produce an "empty set" expression that is specific to a target
-backend, such as "SELECT CAST(NULL AS INTEGER) WHERE 1!=1" for Postgresql,
+backend, such as "SELECT CAST(NULL AS INTEGER) WHERE 1!=1" for PostgreSQL,
"SELECT 1 FROM (SELECT 1) as _empty_set WHERE 1!=1" for MySQL::
>>> from sqlalchemy import create_engine
The feature also works for tuple-oriented IN statements, where the "empty IN"
expression will be expanded to support the elements given inside the tuple,
-such as on Postgresql::
+such as on PostgreSQL::
>>> from sqlalchemy import create_engine
>>> from sqlalchemy import select, literal_column, tuple_, bindparam
.. _change_4237:
-Added basic reflection support for Postgresql paritioned tables
----------------------------------------------------------------
+Added basic reflection support for PostgreSQL partitioned tables
+----------------------------------------------------------------
-SQLAlchemy can render the "PARTITION BY" sequnce within a Postgresql
+SQLAlchemy can render the "PARTITION BY" sequence within a PostgreSQL
CREATE TABLE statement using the flag ``postgresql_partition_by``, added in
version 1.2.6. However, the ``'p'`` type was not part of the reflection
queries used until now.
Fixed issue where multiple :class:`.postgresql.ENUM` objects referred to
by the same :class:`.MetaData` object would fail to be created if
multiple objects had the same name under different schema names. The
- internal memoization the Postgresql dialect uses to track if it has
+ internal memoization the PostgreSQL dialect uses to track if it has
created a particular :class:`.postgresql.ENUM` in the database during
a DDL creation sequence now takes schema name into account.
like a regular ad-hoc function. This to suit the case that many of
these functions on specific backends accept arguments such as
"fractional seconds" precision and such. If the function is created
- with arguments, it renders the the parenthesis and the arguments. If
- no arguents are present, the compiler generates the non-parenthesized form.
+ with arguments, it renders the parenthesis and the arguments. If
+ no arguments are present, the compiler generates the non-parenthesized form.
Associating a Sequence as the Server Side Default
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.. note:: The following technique is known to work only with the Postgresql
+.. note:: The following technique is known to work only with the PostgreSQL
database. It does not work with Oracle.
The preceding sections illustrate how to associate a :class:`.Sequence` with a
where(addresses.c.email_address.startswith('ed%'))
conn.execute(stmt)
-On a Postgresql backend, the resulting SQL from the above statement would render as::
+On a PostgreSQL backend, the resulting SQL from the above statement would render as::
DELETE FROM users USING addresses
WHERE users.id = addresses.id
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):
Note that selectin polymorphic loading has similar caveats as that of
selectin relationship loading; for entities that make use of a composite
primary key, the database in use must support tuples with "IN", currently
-known to work with MySQL and Postgresql.
+known to work with MySQL and PostgreSQL.
.. versionadded:: 1.2
.. autofunction:: sqlalchemy.orm.with_polymorphic
-.. autofunction:: sqlalchemy.orm.selectin_polymorphic
\ No newline at end of file
+.. autofunction:: sqlalchemy.orm.selectin_polymorphic
clause, e.g. windowing. Alternatively, consider using "select IN" eager loading
which is **potentially** compatible with :meth:`.Query.yield_per`, provided
that the database driver in use supports multiple, simultaneous cursors
-(SQLite, Postgresql drivers, not MySQL drivers or SQL Server ODBC drivers).
+(SQLite, PostgreSQL drivers, not MySQL drivers or SQL Server ODBC drivers).
.. _zen_of_eager_loading:
with a top limit on memory use when used with :meth:`.Query.yield_per`.
Current database drivers that support simultaneous cursors include
- SQLite, Postgresql. The MySQL drivers mysqlclient and pymysql currently
+ SQLite, PostgreSQL. The MySQL drivers mysqlclient and pymysql currently
**do not** support simultaneous cursors, nor do the ODBC drivers for
SQL Server.
keys, it must use the "tuple" form of IN, which looks like
``WHERE (table.column_a, table.column_b) IN ((?, ?), (?, ?), (?, ?))``.
This syntax is not supported on every database; currently it is known
- to be only supported by modern Postgresql and MySQL versions. Therefore
+ to be only supported by modern PostgreSQL and MySQL versions. Therefore
**selectin loading is not platform-agnostic for composite primary keys**.
There is no special logic in SQLAlchemy to check ahead of time which platforms
support this syntax or not; if run against a non-supporting platform (such
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
conn.execute(on_duplicate_key_stmt)
-Unlike Postgresql's "ON CONFLICT" phrase, the "ON DUPLICATE KEY UPDATE"
+Unlike PostgreSQL's "ON CONFLICT" phrase, the "ON DUPLICATE KEY UPDATE"
phrase will always match on any primary key or unique key, and will always
perform an UPDATE if there's a match; there are no options for it to raise
an error or to skip performing an UPDATE.
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
# the right side as given often needs to be adapted. additionally
# a lot of things can be wrong with it. handle all that and
- # get back the the new effective "right" side
+ # get back the new effective "right" side
r_info, right, onclause = self._join_check_and_adapt_right_side(
left, right, onclause, prop, create_aliases,
)
**self._select_args
)
# put FOR UPDATE on the inner query, where MySQL will honor it,
- # as well as if it has an OF so Postgresql can use it.
+ # as well as if it has an OF so PostgreSQL can use it.
inner._for_update_arg = context._for_update_arg
for hint in self._with_hints:
use_labels=context.labels)
# Oracle however does not allow FOR UPDATE on the subquery,
- # and the Oracle dialect ignores it, plus for Postgresql, MySQL
+ # and the Oracle dialect ignores it, plus for PostgreSQL, MySQL
# we expect that all elements of the row are locked, so also put it
# on the outside (except in the case of PG when OF is used)
if context._for_update_arg is not None and \
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",
"""target system has a strong concept of 'default' schema that can
be referred to implicitly.
- basically, Postgresql.
+ basically, PostgreSQL.
"""
return only_on([
is_true(y_copy.type._create_events)
- # for Postgresql, this will emit CREATE TYPE
+ # for PostgreSQL, this will emit CREATE TYPE
m.dispatch.before_create(t1, testing.db)
try:
eq_(t1.c.y.type.evt_targets, (t1, ))
finally:
- # do the drop so that Postgresql emits DROP TYPE
+ # do the drop so that PostgreSQL emits DROP TYPE
m.dispatch.after_drop(t1, testing.db)
def test_enum_nonnative_column_copy_transfers_events(self):
def test_alias_handles_column_context(self):
# not quite a use case yet but this is expected to become
- # prominent w/ Postgresql's tuple functions
+ # prominent w/ PostgreSQL's tuple functions
stmt = select([table1.c.col1, table1.c.col2])
a = stmt.alias('a')
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
