From: Lele Gaifax Date: Mon, 31 Dec 2018 02:16:11 +0000 (-0500) Subject: commit 1b774808c926665047bf353222ecd191679a95d1 X-Git-Tag: rel_1_3_0b2~50 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c0f9708fde39175c8695fdd87873464f516fdf98;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git commit 1b774808c926665047bf353222ecd191679a95d1 Author: Lele Gaifax Date: Tue Dec 25 12:35:41 2018 +0100 Consistently use "PostgreSQL", fixing also a few doc glitches commit 0e382aaee4427193926f0dc10ad29056bc12c85e Author: Lele Gaifax Date: Tue Dec 25 12:08:49 2018 +0100 Remove duplicated words Change-Id: Iaa586b9412f46a50fe6ff3bbb92e07d6cb1905c8 --- diff --git a/README.unittests.rst b/README.unittests.rst index 28924531ed..c32837f780 100644 --- a/README.unittests.rst +++ b/README.unittests.rst @@ -23,7 +23,7 @@ Python 2.7 using an in-memory SQLite database:: 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 @@ -64,13 +64,13 @@ quickly allow for custom database connections. Example:: 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 diff --git a/doc/build/changelog/changelog_10.rst b/doc/build/changelog/changelog_10.rst index 93812d5e2e..1ae1f32162 100644 --- a/doc/build/changelog/changelog_10.rst +++ b/doc/build/changelog/changelog_10.rst @@ -217,7 +217,7 @@ ``_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 @@ -703,7 +703,7 @@ 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:: diff --git a/doc/build/changelog/changelog_11.rst b/doc/build/changelog/changelog_11.rst index 9b25c42298..dcd4722d06 100644 --- a/doc/build/changelog/changelog_11.rst +++ b/doc/build/changelog/changelog_11.rst @@ -41,7 +41,7 @@ :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. @@ -130,7 +130,7 @@ :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:: @@ -251,7 +251,7 @@ :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. @@ -270,7 +270,7 @@ :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. @@ -467,12 +467,12 @@ :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 @@ -635,7 +635,7 @@ 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. @@ -671,7 +671,7 @@ :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. @@ -784,7 +784,7 @@ :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. @@ -838,7 +838,7 @@ :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`. @@ -1129,7 +1129,7 @@ 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:: @@ -1175,7 +1175,7 @@ :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. diff --git a/doc/build/changelog/changelog_12.rst b/doc/build/changelog/changelog_12.rst index edcf1f40b6..e1b01f62c0 100644 --- a/doc/build/changelog/changelog_12.rst +++ b/doc/build/changelog/changelog_12.rst @@ -834,7 +834,7 @@ :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. @@ -871,7 +871,7 @@ 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:: @@ -901,7 +901,7 @@ .. 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. @@ -1325,7 +1325,7 @@ :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 @@ -1859,7 +1859,7 @@ :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). @@ -2150,7 +2150,7 @@ 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:: @@ -2330,7 +2330,7 @@ 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. @@ -2344,7 +2344,7 @@ :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 @@ -2482,7 +2482,7 @@ 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:: @@ -2518,7 +2518,7 @@ 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 diff --git a/doc/build/changelog/changelog_13.rst b/doc/build/changelog/changelog_13.rst index 2f023dcd27..8649241e1c 100644 --- a/doc/build/changelog/changelog_13.rst +++ b/doc/build/changelog/changelog_13.rst @@ -175,7 +175,7 @@ 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. @@ -237,7 +237,7 @@ :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. diff --git a/doc/build/changelog/migration_11.rst b/doc/build/changelog/migration_11.rst index aa751a6c3e..43d3dab379 100644 --- a/doc/build/changelog/migration_11.rst +++ b/doc/build/changelog/migration_11.rst @@ -1652,9 +1652,9 @@ retained as None/NULL. 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). @@ -2220,7 +2220,7 @@ expressions to :meth:`.Query.distinct`, the above "column adding" logic 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. diff --git a/doc/build/changelog/migration_12.rst b/doc/build/changelog/migration_12.rst index e2df229537..7d01797502 100644 --- a/doc/build/changelog/migration_12.rst +++ b/doc/build/changelog/migration_12.rst @@ -140,7 +140,7 @@ The above SELECT statement includes these advantages: * 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`. @@ -151,7 +151,7 @@ will have more additional "SELECT IN" queries following. Also, support 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:: @@ -779,7 +779,7 @@ follows:: 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 @@ -794,7 +794,7 @@ With the compilation-time behavior, the dialect itself can be instructed 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 @@ -873,7 +873,7 @@ the above table is autoloaded or inspected with :meth:`.Inspector.get_columns`, 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` @@ -884,7 +884,7 @@ Multiple-table criteria support for DELETE 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. @@ -896,7 +896,7 @@ Given a statement as:: 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 @@ -919,8 +919,8 @@ The "autoescape" parameter is added to :meth:`.ColumnOperators.startswith`, 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. @@ -1452,7 +1452,7 @@ same as the left-hand expression:: 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`:: @@ -1570,7 +1570,7 @@ on by default in a future release. 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:: diff --git a/doc/build/changelog/migration_13.rst b/doc/build/changelog/migration_13.rst index fcc6776f96..dd1f9009e0 100644 --- a/doc/build/changelog/migration_13.rst +++ b/doc/build/changelog/migration_13.rst @@ -77,8 +77,8 @@ lazy loading uses in order to determine if related entities can be fetched 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. @@ -716,7 +716,7 @@ combined with "SELECT..FOR UPDATE", the behavior has been this:: ) 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 ( @@ -725,11 +725,11 @@ So the above query now renders as:: 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:: @@ -742,7 +742,7 @@ The query would now render as:: 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. @@ -948,7 +948,7 @@ Expanding IN feature now supports empty lists 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 @@ -965,7 +965,7 @@ backend, such as "SELECT CAST(NULL AS INTEGER) WHERE 1!=1" for Postgresql, 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 @@ -1062,10 +1062,10 @@ Dialect Improvements and Changes - PostgreSQL .. _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. diff --git a/doc/build/changelog/unreleased_12/4416.rst b/doc/build/changelog/unreleased_12/4416.rst index 3eac7f2112..4e5f3dd5b2 100644 --- a/doc/build/changelog/unreleased_12/4416.rst +++ b/doc/build/changelog/unreleased_12/4416.rst @@ -14,6 +14,6 @@ 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. diff --git a/doc/build/changelog/unreleased_13/4386.rst b/doc/build/changelog/unreleased_13/4386.rst index 24e9f848bd..b5e89a1d38 100644 --- a/doc/build/changelog/unreleased_13/4386.rst +++ b/doc/build/changelog/unreleased_13/4386.rst @@ -7,5 +7,5 @@ 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. diff --git a/doc/build/core/defaults.rst b/doc/build/core/defaults.rst index 0d5a1e89bc..cf7a8a468d 100644 --- a/doc/build/core/defaults.rst +++ b/doc/build/core/defaults.rst @@ -428,7 +428,7 @@ and that options like default schema are propagated, setting the 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 diff --git a/doc/build/core/tutorial.rst b/doc/build/core/tutorial.rst index a991532273..e0382b89f2 100644 --- a/doc/build/core/tutorial.rst +++ b/doc/build/core/tutorial.rst @@ -2155,7 +2155,7 @@ implicitly, by specifying multiple tables in the WHERE clause:: 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 diff --git a/doc/build/orm/cascades.rst b/doc/build/orm/cascades.rst index 0a0f23a707..8886621ae9 100644 --- a/doc/build/orm/cascades.rst +++ b/doc/build/orm/cascades.rst @@ -131,7 +131,7 @@ delete 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): diff --git a/doc/build/orm/inheritance_loading.rst b/doc/build/orm/inheritance_loading.rst index 9e316bcb19..09631c6c2c 100644 --- a/doc/build/orm/inheritance_loading.rst +++ b/doc/build/orm/inheritance_loading.rst @@ -475,7 +475,7 @@ the one against ``Manager`` will be: 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 @@ -905,4 +905,4 @@ Inheritance Loading API .. autofunction:: sqlalchemy.orm.with_polymorphic -.. autofunction:: sqlalchemy.orm.selectin_polymorphic \ No newline at end of file +.. autofunction:: sqlalchemy.orm.selectin_polymorphic diff --git a/doc/build/orm/loading_relationships.rst b/doc/build/orm/loading_relationships.rst index f883897d86..4a57aad34e 100644 --- a/doc/build/orm/loading_relationships.rst +++ b/doc/build/orm/loading_relationships.rst @@ -391,7 +391,7 @@ SELECT statements, each referring to a subset of rows using the WHERE 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: @@ -811,7 +811,7 @@ as of the 1.2 series. Things to know about this kind of loading include: 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. @@ -819,7 +819,7 @@ as of the 1.2 series. Things to know about this kind of loading include: 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 diff --git a/doc/build/orm/persistence_techniques.rst b/doc/build/orm/persistence_techniques.rst index 7c1db2dd96..c25c68e17e 100644 --- a/doc/build/orm/persistence_techniques.rst +++ b/doc/build/orm/persistence_techniques.rst @@ -345,7 +345,7 @@ outside of the database's usual autoincrement routine. In this case, we have to 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 diff --git a/doc/build/orm/session_transaction.rst b/doc/build/orm/session_transaction.rst index bd06286a6e..6b33a68781 100644 --- a/doc/build/orm/session_transaction.rst +++ b/doc/build/orm/session_transaction.rst @@ -150,7 +150,7 @@ methods are called. 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 diff --git a/lib/sqlalchemy/dialects/mysql/base.py b/lib/sqlalchemy/dialects/mysql/base.py index a021551997..d633c2f65c 100644 --- a/lib/sqlalchemy/dialects/mysql/base.py +++ b/lib/sqlalchemy/dialects/mysql/base.py @@ -359,7 +359,7 @@ the generative method :meth:`~.mysql.dml.Insert.on_duplicate_key_update`:: 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. diff --git a/lib/sqlalchemy/dialects/sqlite/base.py b/lib/sqlalchemy/dialects/sqlite/base.py index 566814375f..c487af8981 100644 --- a/lib/sqlalchemy/dialects/sqlite/base.py +++ b/lib/sqlalchemy/dialects/sqlite/base.py @@ -189,7 +189,7 @@ The other axis along which SQLite's transactional locking is impacted is via the nature of the ``BEGIN`` statement used. The three varieties are "deferred", "immediate", and "exclusive", as described at `BEGIN TRANSACTION `_. 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 diff --git a/lib/sqlalchemy/orm/query.py b/lib/sqlalchemy/orm/query.py index df8add27d2..febf627b4a 100644 --- a/lib/sqlalchemy/orm/query.py +++ b/lib/sqlalchemy/orm/query.py @@ -2331,7 +2331,7 @@ class Query(object): # 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, ) @@ -3722,7 +3722,7 @@ class Query(object): **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: @@ -3742,7 +3742,7 @@ class Query(object): 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 \ diff --git a/lib/sqlalchemy/sql/sqltypes.py b/lib/sqlalchemy/sql/sqltypes.py index d40fedc850..c5708940b4 100644 --- a/lib/sqlalchemy/sql/sqltypes.py +++ b/lib/sqlalchemy/sql/sqltypes.py @@ -1894,13 +1894,13 @@ class JSON(Indexable, TypeEngine): 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**:: diff --git a/lib/sqlalchemy/testing/plugin/plugin_base.py b/lib/sqlalchemy/testing/plugin/plugin_base.py index 8939ff7c65..0ffcae0936 100644 --- a/lib/sqlalchemy/testing/plugin/plugin_base.py +++ b/lib/sqlalchemy/testing/plugin/plugin_base.py @@ -66,7 +66,7 @@ def setup_options(make_option): 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", diff --git a/test/requirements.py b/test/requirements.py index 3948d751d0..6c9c5a7606 100644 --- a/test/requirements.py +++ b/test/requirements.py @@ -418,7 +418,7 @@ class DefaultRequirements(SuiteRequirements): """target system has a strong concept of 'default' schema that can be referred to implicitly. - basically, Postgresql. + basically, PostgreSQL. """ return only_on([ diff --git a/test/sql/test_metadata.py b/test/sql/test_metadata.py index d0fa04d78a..f030a7e77c 100644 --- a/test/sql/test_metadata.py +++ b/test/sql/test_metadata.py @@ -1858,12 +1858,12 @@ class SchemaTypeTest(fixtures.TestBase): 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): diff --git a/test/sql/test_selectable.py b/test/sql/test_selectable.py index 0cbaf33ea7..4b92e3e3ec 100644 --- a/test/sql/test_selectable.py +++ b/test/sql/test_selectable.py @@ -335,7 +335,7 @@ class SelectableTest( 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')