:tags: feature, postgresql
:tickets: 3529
- Added support for Postgresql's INSERT..ON CONFLICT using a new
- Postgresql-specific :class:`.postgresql.dml.Insert` object.
+ Added support for PostgreSQL's INSERT..ON CONFLICT using a new
+ PostgreSQL-specific :class:`.postgresql.dml.Insert` object.
Pull request and extensive efforts here by Robin Thomas.
.. seealso::
The DDL for DROP INDEX will emit "CONCURRENTLY" if the
``postgresql_concurrently`` flag is set upon the
:class:`.Index` and if the database in use is detected as
- Postgresql version 9.2 or greater. For CREATE INDEX, database
+ PostgreSQL version 9.2 or greater. For CREATE INDEX, database
version detection is also added which will omit the clause if
PG version is less than 8.2. Pull request courtesy Iuri de Silvio.
:tickets: 3720
Added ``postgresql_tablespace`` as an argument to :class:`.Index`
- to allow specification of TABLESPACE for an index in Postgresql.
+ to allow specification of TABLESPACE for an index in PostgreSQL.
Complements the same-named parameter on :class:`.Table`. Pull
request courtesy Benjamin Bertrand.
:tags: feature, sql
:pullreq: bitbucket:80
- Implemented reflection of CHECK constraints for SQLite and Postgresql.
+ Implemented reflection of CHECK constraints for SQLite and PostgreSQL.
This is available via the new inspector method
:meth:`.Inspector.get_check_constraints` as well as when reflecting
:class:`.Table` objects in the form of :class:`.CheckConstraint`
:paramref:`.GenerativeSelect.with_for_update.key_share`, which
will render the ``FOR NO KEY UPDATE`` version of ``FOR UPDATE``
and ``FOR KEY SHARE`` instead of ``FOR SHARE``
- on the Postgresql backend. Pull request courtesy Sergey Skopin.
+ on the PostgreSQL backend. Pull request courtesy Sergey Skopin.
.. change::
:tags: feature, postgresql, oracle
Added new parameter
:paramref:`.GenerativeSelect.with_for_update.skip_locked`, which
will render the ``SKIP LOCKED`` phrase for a ``FOR UPDATE`` or
- ``FOR SHARE`` lock on the Postgresql and Oracle backends. Pull
+ ``FOR SHARE`` lock on the PostgreSQL and Oracle backends. Pull
request courtesy Jack Zhou.
.. change::
.. change::
:tags: feature, postgresql
- Added a new dialect for the PyGreSQL Postgresql dialect. Thanks
+ Added a new dialect for the PyGreSQL PostgreSQL dialect. Thanks
to Christoph Zwerschke and Kaolin Imago Fire for their efforts.
.. change::
Added :meth:`.Select.lateral` and related constructs to allow
for the SQL standard LATERAL keyword, currently only supported
- by Postgresql.
+ by PostgreSQL.
.. seealso::
when the construct contains non-standard SQL elements such as
RETURNING, array index operations, or dialect-specific or custom
datatypes. A string is now returned in these cases rendering an
- approximation of the construct (typically the Postgresql-style
+ approximation of the construct (typically the PostgreSQL-style
version of it) rather than raising an error.
.. seealso::
:tickets: 3587
Added support for reflecting the source of materialized views
- to the Postgresql version of the :meth:`.Inspector.get_view_definition`
+ to the PostgreSQL version of the :meth:`.Inspector.get_view_definition`
method.
.. change::
or :class:`.Boolean` with regards to ensuring that the per-table
events are propagated from the implementation type to the outer type.
These events are used
- to ensure that the constraints or Postgresql types (e.g. ENUM)
+ to ensure that the constraints or PostgreSQL types (e.g. ENUM)
are correctly created (and possibly dropped) along with the parent
table.
and supports index / slice operations, as well as
:func:`.postgresql.array_agg`, which returns a :class:`.postgresql.ARRAY`
with additional comparison features. As arrays are only
- supported on Postgresql at the moment, only actually works on
- Postgresql. Also added a new construct
+ supported on PostgreSQL at the moment, only actually works on
+ PostgreSQL. Also added a new construct
:class:`.postgresql.aggregate_order_by` in support of PG's
"ORDER BY" extension.
on other databases that have an "array" concept, such as DB2 or Oracle.
Additionally, new operators :func:`.expression.any_` and
:func:`.expression.all_` have been added. These support not just
- array constructs on Postgresql, but also subqueries that are usable
- on MySQL (but sadly not on Postgresql).
+ array constructs on PostgreSQL, but also subqueries that are usable
+ on MySQL (but sadly not on PostgreSQL).
.. seealso::
:tags: bug, postgresql
:tickets: 3487
- The Postgresql :class:`.postgresql.ARRAY` type now supports multidimensional
+ The PostgreSQL :class:`.postgresql.ARRAY` type now supports multidimensional
indexed access, e.g. expressions such as ``somecol[5][6]`` without
any need for explicit casts or type coercions, provided
that the :paramref:`.postgresql.ARRAY.dimensions` parameter is set to the
:tickets: 3503
The return type for the :class:`.postgresql.JSON` and :class:`.postgresql.JSONB`
- when using indexed access has been fixed to work like Postgresql itself,
+ when using indexed access has been fixed to work like PostgreSQL itself,
and returns an expression that itself is of type :class:`.postgresql.JSON`
or :class:`.postgresql.JSONB`. Previously, the accessor would return
:class:`.NullType` which disallowed subsequent JSON-like operators to be
:tickets: 3514
Additional fixes have been made regarding the value of ``None``
- in conjunction with the Postgresql :class:`.postgresql.JSON` type. When
+ in conjunction with the PostgreSQL :class:`.postgresql.JSON` type. When
the :paramref:`.JSON.none_as_null` flag is left at its default
value of ``False``, the ORM will now correctly insert the Json
"'null'" string into the column whenever the value on the ORM
of filtering on additional columns.
This deduplication relies upon the hashability of the elements within
-the row. With the introduction of Postgresql's special types like
+the row. With the introduction of PostgreSQL's special types like
:class:`.postgresql.ARRAY`, :class:`.postgresql.HSTORE` and
:class:`.postgresql.JSON`, the experience of types within rows being
unhashable and encountering problems here is more prevalent than
In fact, SQLAlchemy has since version 0.8 included a flag on datatypes that
are noted as "unhashable", however this flag was not used consistently
on built in types. As described in :ref:`change_3499_postgresql`, this
-flag is now set consistently for all of Postgresql's "structural" types.
+flag is now set consistently for all of PostgreSQL's "structural" types.
The "unhashable" flag is also set on the :class:`.NullType` type,
as :class:`.NullType` is used to refer to any expression of unknown
New options allowing explicit persistence of NULL over a default
----------------------------------------------------------------
-Related to the new JSON-NULL support added to Postgresql as part of
+Related to the new JSON-NULL support added to PostgreSQL as part of
:ref:`change_3514`, the base :class:`.TypeEngine` class now supports
a method :meth:`.TypeEngine.evaluates_none` which allows a positive set
of the ``None`` value on an attribute to be persisted as NULL, rather than
would not be affected, as the additional columns are not included in the
result in any case, but the columns are unnecessary.
-Additionally, when the Postgresql DISTINCT ON format is used by passing
+Additionally, when the PostgreSQL DISTINCT ON format is used by passing
expressions to :meth:`.Query.distinct`, the above "column adding" logic
is disabled entirely.
Support for the SQL LATERAL keyword
------------------------------------
-The LATERAL keyword is currently known to only be supported by Postgresql 9.3
+The LATERAL keyword is currently known to only be supported by PostgreSQL 9.3
and greater, however as it is part of the SQL standard support for this keyword
is added to Core. The implementation of :meth:`.Select.lateral` employs
special logic beyond just rendering the LATERAL keyword to allow for
"autoincrement" feature for a single-column integer primary key; by "autoincrement"
we mean that the database column will include whatever DDL directives the
database provides in order to indicate an auto-incrementing integer identifier,
-such as the SERIAL keyword on Postgresql or AUTO_INCREMENT on MySQL, and additionally
+such as the SERIAL keyword on PostgreSQL or AUTO_INCREMENT on MySQL, and additionally
that the dialect will recieve these generated values from the execution
of a :meth:`.Table.insert` construct using techniques appropriate to that
backend.
JSON support added to Core
--------------------------
-As MySQL now has a JSON datatype in addition to the Postgresql JSON datatype,
+As MySQL now has a JSON datatype in addition to the PostgreSQL JSON datatype,
the core now gains a :class:`sqlalchemy.types.JSON` datatype that is the basis
for both of these. Using this type allows access to the "getitem" operator
-as well as the "getpath" operator in a way that is agnostic across Postgresql
+as well as the "getpath" operator in a way that is agnostic across PostgreSQL
and MySQL.
The new datatype also has a series of improvements to the handling of
Array support added to Core; new ANY and ALL operators
------------------------------------------------------
-Along with the enhancements made to the Postgresql :class:`.postgresql.ARRAY`
+Along with the enhancements made to the PostgreSQL :class:`.postgresql.ARRAY`
type described in :ref:`change_3503`, the base class of :class:`.postgresql.ARRAY`
itself has been moved to Core in a new class :class:`.types.ARRAY`.
for not just PostgreSQL but also potentially for other array-capable backends
in the future such as DB2, the majority of array logic for SQL expressions
is now in Core. The :class:`.types.ARRAY` type still **only works on
-Postgresql**, however it can be used directly, supporting special array
+PostgreSQL**, however it can be used directly, supporting special array
use cases such as indexed access, as well as support for the ANY and ALL::
mytable = Table("mytable", metadata,
The :func:`.sql.expression.any_` and :func:`.sql.expression.all_` operators
are open-ended at the Core level, however their interpretation by backend
-databases is limited. On the Postgresql backend, the two operators
+databases is limited. On the PostgreSQL backend, the two operators
**only accept array values**. Whereas on the MySQL backend, they
**only accept subquery values**. On MySQL, one can use an expression
such as::
from sqlalchemy import func
stmt = select([func.array_agg(table.c.value)])
-A Postgresql element for an aggregate ORDER BY is also added via
+A PostgreSQL element for an aggregate ORDER BY is also added via
:class:`.postgresql.aggregate_order_by`::
from sqlalchemy.dialects.postgresql import aggregate_order_by
The :class:`.SchemaType` types include types such as :class:`.Enum`
and :class:`.Boolean` which, in addition to corresponding to a database
-type, also generate either a CHECK constraint or in the case of Postgresql
+type, also generate either a CHECK constraint or in the case of PostgreSQL
ENUM a new CREATE TYPE statement, will now work automatically with
:class:`.TypeDecorator` recipes. Previously, a :class:`.TypeDecorator` for
an :class:`.postgresql.ENUM` had to look like this::
ON pets_1.person_id = CAST(person.id AS INTEGER)
Without the CAST in the ON clause of the join, strongly-typed databases
-such as Postgresql will refuse to implicitly compare the integer and fail.
+such as PostgreSQL will refuse to implicitly compare the integer and fail.
The lazyload case of ``.pets`` relies upon replacing
the ``Person.id`` column at load time with a bound parameter, which receives
:ref:`change_3501`
-Dialect Improvements and Changes - Postgresql
+Dialect Improvements and Changes - PostgreSQL
=============================================
.. _change_3529:
Support for INSERT..ON CONFLICT (DO UPDATE | DO NOTHING)
--------------------------------------------------------
-The ``ON CONFLICT`` clause of ``INSERT`` added to Postgresql as of
-version 9.5 is now supported using a Postgresql-specific version of the
+The ``ON CONFLICT`` clause of ``INSERT`` added to PostgreSQL as of
+version 9.5 is now supported using a PostgreSQL-specific version of the
:class:`.Insert` object, via :func:`sqlalchemy.dialects.postgresql.dml.insert`.
This :class:`.Insert` subclass adds two new methods :meth:`.Insert.on_conflict_do_update`
and :meth:`.Insert.on_conflict_do_nothing` which implement the full syntax
-supported by Posgresql 9.5 in this area::
+supported by PostgreSQL 9.5 in this area::
from sqlalchemy.dialects.postgresql import insert
type :class:`.Integer` where we could no longer perform indexed access
for the remaining dimensions, unless we used :func:`.cast` or :func:`.type_coerce`.
-* The :class:`~.postgresql.JSON` and :class:`~.postgresql.JSONB` types now mirror what Postgresql
+* The :class:`~.postgresql.JSON` and :class:`~.postgresql.JSONB` types now mirror what PostgreSQL
itself does for indexed access. This means that all indexed access for
a :class:`~.postgresql.JSON` or :class:`~.postgresql.JSONB` type returns an expression that itself
is *always* :class:`~.postgresql.JSON` or :class:`~.postgresql.JSONB` itself, unless the
:attr:`~.postgresql.JSON.Comparator.astext` modifier is used. This means that whether
the indexed access of the JSON structure ultimately refers to a string,
- list, number, or other JSON structure, Postgresql always considers it
+ list, number, or other JSON structure, PostgreSQL always considers it
to be JSON itself unless it is explicitly cast differently. Like
the :class:`~.postgresql.ARRAY` type, this means that it is now straightforward
to produce JSON expressions with multiple levels of indexed access::
Check constraints now reflect
-----------------------------
-The Postgresql dialect now supports reflection of CHECK constraints
+The PostgreSQL dialect now supports reflection of CHECK constraints
both within the method :meth:`.Inspector.get_check_constraints` as well
as within :class:`.Table` reflection within the :attr:`.Table.constraints`
collection.
The new parameters :paramref:`.GenerativeSelect.with_for_update.skip_locked`
and :paramref:`.GenerativeSelect.with_for_update.key_share`
in both Core and ORM apply a modification to a "SELECT...FOR UPDATE"
-or "SELECT...FOR SHARE" query on the Postgresql backend:
+or "SELECT...FOR SHARE" query on the PostgreSQL backend:
* SELECT FOR NO KEY UPDATE::
the JSON type newly added to MySQL 5.7. This type provides both persistence
of JSON as well as rudimentary indexed-access using the ``JSON_EXTRACT``
function internally. An indexable JSON column that works across MySQL
-and Postgresql can be achieved by using the :class:`.types.JSON` datatype
-common to both MySQL and Postgresql.
+and PostgreSQL can be achieved by using the :class:`.types.JSON` datatype
+common to both MySQL and PostgreSQL.
.. seealso::
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
