summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/dialects/postgresql
Commit message (Collapse)AuthorAgeFilesLines
...
| * Add MACCADDR8 for PGCompilerasimfarooq52022-12-193-0/+16
| | | | | | | | | | | | | | | | | | | | Add MACCADDR8 for PGCompiler Closes: #8393 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8393 Pull-request-sha: 837a68eba3e31e0acbb7c47ee87bca4e9def7648 Change-Id: I87e4999eb8d82662ff8ab409c98dc57edd7fd271
* | ensure all visit methods accept **kwMike Bayer2022-12-161-10/+10
| | | | | | | | | | | | | | | | | | | | Added test support to ensure that all compiler ``visit_xyz()`` methods across all :class:`.Compiler` implementations in SQLAlchemy accept a ``**kw`` parameter, so that all compilers accept additional keyword arguments under all circumstances. Fixes: #8988 Change-Id: I1cefc313e4e64a10ee7dd14400137fbe02ce9523
* | Merge "add explicit REGCONFIG, pg full text functions" into mainmike bayer2022-12-166-2/+317
|\ \
| * | add explicit REGCONFIG, pg full text functionsMike Bayer2022-12-156-2/+317
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added support for explicit use of PG full text functions with asyncpg and psycopg (SQLAlchemy 2.0 only), with regards to the ``REGCONFIG`` type cast for the first argument, which previously would be incorrectly cast to a VARCHAR, causing failures on these dialects that rely upon explicit type casts. This includes support for :class:`_postgresql.to_tsvector`, :class:`_postgresql.to_tsquery`, :class:`_postgresql.plainto_tsquery`, :class:`_postgresql.phraseto_tsquery`, :class:`_postgresql.websearch_to_tsquery`, :class:`_postgresql.ts_headline`, each of which will determine based on number of arguments passed if the first string argument should be interpreted as a PostgreSQL "REGCONFIG" value; if so, the argument is typed using a newly added type object :class:`_postgresql.REGCONFIG` which is then explicitly cast in the SQL expression. Fixes: #8977 Change-Id: Ib36698a984fd4194bd6e0eb663105f790f3db7d3
* | Fix equality comparison between a PG Range and a different class instanceLele Gaifax2022-12-151-4/+7
|/ | | | | | | | | | This fixes issue #8984, making the method `Range.__eq__` return `NotImplemented` when the argument is an instance of a different class. Closes: #8985 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8985 Pull-request-sha: b8f601f038a2203af02a99ab190ebbc1c489549a Change-Id: Iaf0b651a22a9f346c8f18b3a53e3339bf61bb33f
* Merge "Add compatibility properties to Range; implement pep-484" into mainmike bayer2022-12-051-82/+164
|\
| * Add compatibility properties to Range; implement pep-484Lele Gaifax2022-12-051-82/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a bunch of properties to new PG Range class for compatibility with other implementations, providing a more similar API to access emptiness and bounds status. The naming conventions here derive from PostgreSQL itself, see https://www.postgresql.org/docs/9.3/functions-range.html . pep-484 also implemented by Mike, as this is a pretty type-intensive module. Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Closes: #8927 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8927 Pull-request-sha: 8b9e7b7e3345673b43aeabd7ec88b88dc3cfa7eb Change-Id: I0b1d49311517ee1cc1377a974ed0a860ea5756e4
* | Rewrite positional handling, test for "numeric"Federico Caselli2022-12-051-14/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changed how the positional compilation is performed. It's rendered by the compiler the same as the pyformat compilation. The string is then processed to replace the placeholders with the correct ones, and to obtain the correct order of the parameters. This vastly simplifies the computation of the order of the parameters, that in case of nested CTE is very hard to compute correctly. Reworked how numeric paramstyle behavers: - added support for repeated parameter, without duplicating them like in normal positional dialects - implement insertmany support. This requires that the dialect supports out of order placehoders, since all parameters that are not part of the VALUES clauses are placed at the beginning of the parameter tuple - support for different identifiers for a numeric parameter. It's for example possible to use postgresql style placeholder $1, $2, etc Added two new dialect based on sqlite to test "numeric" fully using both :1 style and $1 style. Includes a workaround for SQLite's not-really-correct numeric implementation. Changed parmstyle of asyncpg dialect to use numeric, rendering with its native $ identifiers Fixes: #8926 Fixes: #8849 Change-Id: I7c640467d49adfe6d795cc84296fc7403dcad4d6
* Fix positional compiling bugsFederico Caselli2022-12-011-9/+4
| | | | | | | | | | | Fixed a series of issues regarding positionally rendered bound parameters, such as those used for SQLite, asyncpg, MySQL and others. Some compiled forms would not maintain the order of parameters correctly, such as the PostgreSQL ``regexp_replace()`` function as well as within the "nesting" feature of the :class:`.CTE` construct first introduced in :ticket:`4123`. Fixes: #8827 Change-Id: I9813ed7c358cc5c1e26725c48df546b209a442cb
* Merge "Add value-level hooks for SQL type detection; apply to Range" into mainmike bayer2022-11-291-0/+20
|\
| * Add value-level hooks for SQL type detection; apply to RangeLele Gaifax2022-11-291-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added additional type-detection for the new PostgreSQL :class:`_postgresql.Range` type, where previous cases that allowed the psycopg2-native range objects to be received directly by the DBAPI without SQLAlchemy intercepting them stopped working, as we now have our own value object. The :class:`_postgresql.Range` object has been enhanced such that SQLAlchemy Core detects it in otherwise ambiguous situations (such as comparison to dates) and applies appropriate bind handlers. Pull request courtesy Lele Gaifax. Fixes: #8884 Closes: #8886 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8886 Pull-request-sha: 6e95e08a30597d3735ab38f2f1a2ccabd968852c Change-Id: I3ca277c826dcf4b5644f44eb251345b439a84ee4
* | Rectify PG Range.__bool__, inverting previous logicLele Gaifax2022-11-271-1/+1
|/ | | | | | | | | | The boolness of the range was defined to be equal to its emptiness. As this has been identified as a typo rather than the intended, this inverts the logic, to match common Python behaviour as well as how other popular PG drivers do. Closes: #8885 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8885 Pull-request-sha: 5670cdb920692a62f77b7b6ea312784033de83d9 Change-Id: I6f4a40168b2f037c578e84f7550370411bd42160
* Merge "Issue #8765: implement missing methods on PG Range" into mainmike bayer2022-11-171-94/+403
|\
| * Issue #8765: implement missing methods on PG RangeLele Gaifax2022-11-151-94/+403
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ### Description This PR implements missing methods on the PG `Range` class, as described by issue #8765. ### Checklist This pull request is: - [ ] A documentation / typographical error fix - [ ] A short code fix - [x] A new feature implementation Closes: #8766 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8766 Pull-request-sha: 21c0df86cc0d1502855527e29425fbffc3f45d64 Change-Id: I86fabd966ad1f14a3a86132be741df46965b9aa9
* | Merge "Try running pyupgrade on the code" into mainmike bayer2022-11-1710-135/+125
|\ \
| * | Try running pyupgrade on the codeFederico Caselli2022-11-1610-135/+125
| |/ | | | | | | | | | | | | | | command run is "pyupgrade --py37-plus --keep-runtime-typing --keep-percent-format <files...>" pyupgrade will change assert_ to assertTrue. That was reverted since assertTrue does not exists in sqlalchemy fixtures Change-Id: Ie1ed2675c7b11d893d78e028aad0d1576baebb55
* | accommodate NULL format_type()Mike Bayer2022-11-161-5/+18
|/ | | | | | | | | Made an adjustment to how the PostgreSQL dialect considers column types when it reflects columns from a table, to accommodate for alternative backends which may return NULL from the PG ``format_type()`` function. Fixes: #8748 Change-Id: I6178287aac567210a76afaa5805b825daa7fa4db
* work around Python 3.11 IntEnum issue; update FastIntFlagMike Bayer2022-11-101-1/+1
| | | | | | | | | | | | | | | | | in [1], Python 3.11 seems to have changed the behavior of IntEnum. We didn't notice this because we have our own workaround class already, but typing did. Ensure we remain compatible with IntFlag. This change also modifies FastIntFlag to no longer use global symbols; this is unnecessary as we assign FastIntFlag members explicitly. Use of ``symbol()`` should probably be phased out. [1] https://github.com/python/cpython/issues/99304 Fixes: #8783 Change-Id: I8ae2e871ff1467ae5ca1f63e66b5dae45d4a6c93
* Merge "Implement contains_value(), issubset() and issuperset() on PG Range" ↵mike bayer2022-11-032-0/+208
|\ | | | | | | into main
| * Implement contains_value(), issubset() and issuperset() on PG RangeLele Gaifax2022-11-032-0/+208
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added new methods :meth:`_postgresql.Range.contains` and :meth:`_postgresql.Range.contained_by` to the new :class:`.Range` data object, which mirror the behavior of the PostgreSQL ``@>`` and ``<@`` operators, as well as the :meth:`_postgresql.AbstractRange.comparator_factory.contains` and :meth:`_postgresql.AbstractRange.comparator_factory.contained_by` SQL operator methods. Pull request courtesy Lele Gaifax. Fixes: #8706 Closes: #8707 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8707 Pull-request-sha: 3a74a0d93e63032ebee02992977498c717a077ff Change-Id: Ief81ca5c31448640b26dfbc3defd4dde1d51e366
* | fix event nameMike Bayer2022-11-021-1/+1
|/ | | | | Change-Id: I26af2326034be07f0ebc91dfbf31d00c40acf585 References: #8717
* ensure pool.reset event always called for resetMike Bayer2022-10-301-0/+64
| | | | | | | | | | | | | | | | | | | | | | Added new parameter :paramref:`.PoolEvents.reset.reset_state` parameter to the :meth:`.PoolEvents.reset` event, with deprecation logic in place that will continue to accept event hooks using the previous set of arguments. This indicates various state information about how the reset is taking place and is used to allow custom reset schemes to take place with full context given. Within this change a fix that's also backported to 1.4 is included which re-enables the :meth:`.PoolEvents.reset` event to continue to take place under all circumstances, including when :class:`.Connection` has already "reset" the connection. The two changes together allow custom reset schemes to be implemented using the :meth:`.PoolEvents.reset` event, instead of the :meth:`.PoolEvents.checkin` event (which continues to function as it always has). Change-Id: Ie17c4f55d02beb6f570b9de6b3044baffa7d6df6 Fixes: #8717
* Only convert Range for sqlalchemy Range objectMike Bayer2022-10-213-23/+19
| | | | | | | | | | Refined the new approach to range objects described at :ref:`change_7156` to accommodate driver-specific range and multirange objects, to better accommodate both legacy code as well as when passing results from raw SQL result sets back into new range or multirange expressions. Fixes: #8690 Change-Id: I7e62c47067f695c6380ad0fe2fe19deaf33594d1
* Revert automatic set of sequence start to 1Federico Caselli2022-10-171-2/+6
| | | | | | | | | | | | | | | | | The :class:`.Sequence` construct restores itself to the DDL behavior it had prior to the 1.4 series, where creating a :class:`.Sequence` with no additional arguments will emit a simple ``CREATE SEQUENCE`` instruction **without** any additional parameters for "start value". For most backends, this is how things worked previously in any case; **however**, for MS SQL Server, the default value on this database is ``-2**63``; to prevent this generally impractical default from taking effect on SQL Server, the :paramref:`.Sequence.start` parameter should be provided. As usage of :class:`.Sequence` is unusual for SQL Server which for many years has standardized on ``IDENTITY``, it is hoped that this change has minimal impact. Fixes: #7211 Change-Id: I1207ea10c8cb1528a1519a0fb3581d9621c27b31
* Merge "`aggregate_order_by` now supports cache generation." into mainmike bayer2022-09-261-1/+11
|\
| * `aggregate_order_by` now supports cache generation.Federico Caselli2022-09-251-1/+11
| | | | | | | | | | | | | | | | | | also adjusted CacheKeyFixture to be a general purpose fixture so that sub-components / dialects can run their own cache key tests. Fixes: #8574 Change-Id: I6c66107856aee11e548d357cea77bceee3e316a0
* | Merge "ORM bulk insert via execute" into mainmike bayer2022-09-261-1/+3
|\ \
| * | ORM bulk insert via executeMike Bayer2022-09-241-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * ORM Insert now includes "bulk" mode that will run essentially the same process as session.bulk_insert_mappings; interprets the given list of values as ORM attributes for key names * ORM UPDATE has a similar feature, without RETURNING support, for session.bulk_update_mappings * Added support for upserts to do RETURNING ORM objects as well * ORM UPDATE/DELETE with list of parameters + WHERE criteria is a not implemented; use connection * ORM UPDATE/DELETE defaults to "auto" synchronize_session; use fetch if RETURNING is present, evaluate if not, as "fetch" is much more efficient (no expired object SELECT problem) and less error prone if RETURNING is available UPDATE: howver this is inefficient! please continue to use evaluate for simple cases, auto can move to fetch if criteria not evaluable * "Evaluate" criteria will now not preemptively unexpire and SELECT attributes that were individually expired. Instead, if evaluation of the criteria indicates that the necessary attrs were expired, we expire the object completely (delete) or expire the SET attrs unconditionally (update). This keeps the object in the same unloaded state where it will refresh those attrs on the next pass, for this generally unusual case. (originally #5664) * Core change! update/delete rowcount comes from len(rows) if RETURNING was used. SQLite at least otherwise did not support this. adjusted test_rowcount accordingly * ORM DELETE with a list of parameters at all is also a not implemented as this would imply "bulk", and there is no bulk_delete_mappings (could be, but we dont have that) * ORM insert().values() with single or multi-values translates key names based on ORM attribute names * ORM returning() implemented for insert, update, delete; explcit returning clauses now interpret rows in an ORM context, with support for qualifying loader options as well * session.bulk_insert_mappings() assigns polymorphic identity if not set. * explicit RETURNING + synchronize_session='fetch' is now supported with UPDATE and DELETE. * expanded return_defaults() to work with DELETE also. * added support for composite attributes to be present in the dictionaries used by bulk_insert_mappings and bulk_update_mappings, which is also the new ORM bulk insert/update feature, that will expand the composite values into their individual mapped attributes the way they'd be on a mapped instance. * bulk UPDATE supports "synchronize_session=evaluate", is the default. this does not apply to session.bulk_update_mappings, just the new version * both bulk UPDATE and bulk INSERT, the latter with or without RETURNING, support *heterogenous* parameter sets. session.bulk_insert/update_mappings did this, so this feature is maintained. now cursor result can be both horizontally and vertically spliced :) This is now a long story with a lot of options, which in itself is a problem to be able to document all of this in some way that makes sense. raising exceptions for use cases we haven't supported is pretty important here too, the tradition of letting unsupported things just not work is likely not a good idea at this point, though there are still many cases that aren't easily avoidable Fixes: #8360 Fixes: #7864 Fixes: #7865 Change-Id: Idf28379f8705e403a3c6a937f6a798a042ef2540
* | | Merge "implement batched INSERT..VALUES () () for executemany" into mainmike bayer2022-09-264-160/+82
|\ \ \ | |/ /
| * | implement batched INSERT..VALUES () () for executemanyMike Bayer2022-09-244-160/+82
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the feature is enabled for all built in backends when RETURNING is used, except for Oracle that doesn't need it, and on psycopg2 and mssql+pyodbc it is used for all INSERT statements, not just those that use RETURNING. third party dialects would need to opt in to the new feature by setting use_insertmanyvalues to True. Also adds dialect-level guards against using returning with executemany where we dont have an implementation to suit it. execute single w/ returning still defers to the server without us checking. Fixes: #6047 Fixes: #7907 Change-Id: I3936d3c00003f02e322f2e43fb949d0e6e568304
* | Use aggregate order by instead of order by in subqueryFederico Caselli2022-09-251-25/+23
|/ | | | | Fixes: #8561 Change-Id: I2d9f6bd895061bf8fbc66723930716670791d896
* auto-cast PG range typesMike Bayer2022-09-204-5/+44
| | | | | | | | | | Range type handling has been enhanced so that it automatically renders type casts, so that in-place round trips for statements that don't provide the database with any context don't require the :func:`_sql.cast` construct to be explicit for the database to know the desired type. Change-Id: Id630b726f8a23059dd2f4cbc410bf5229d89cbfb References: #8540
* Use ``;`` instead of ``select 1`` to ping PostgreSQLFederico Caselli2022-09-153-0/+25
| | | | | Fixes: #8491 Change-Id: I941d2a3cf92e5609e2045a53cec94522340951db
* implement icontains, istartswith, iendswith operatorsMatias Martinez Rebori2022-09-081-0/+3
| | | | | | | | | | | | | | | | | | | | Added long-requested case-insensitive string operators :meth:`_sql.ColumnOperators.icontains`, :meth:`_sql.ColumnOperators.istartswith`, :meth:`_sql.ColumnOperators.iendswith`, which produce case-insensitive LIKE compositions (using ILIKE on PostgreSQL, and the LOWER() function on all other backends) to complement the existing LIKE composition operators :meth:`_sql.ColumnOperators.contains`, :meth:`_sql.ColumnOperators.startswith`, etc. Huge thanks to Matias Martinez Rebori for their meticulous and complete efforts in implementing these new methods. Fixes: #3482 Closes: #8496 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8496 Pull-request-sha: 7287e2c436959fac4fef022f359fcc73d1528211 Change-Id: I9fcdd603716218067547cc92a2b07bd02a2c366b
* apply consistent ORM mutable notes for all mutable SQL typesMike Bayer2022-08-302-21/+50
| | | | | | | | | | | | in https://github.com/sqlalchemy/sqlalchemy/discussions/8447 I was surprised that we didnt have any notes about using Mutable for ARRAY classes, since we have them for HSTORE and JSON. Add a consistent topic box for these so we have something to point towards. Change-Id: Idfa1b2cbee67024545f4fa299e4c875075ec7d3f
* integrate connection.terminate() for supporting dialectsMike Bayer2022-08-241-0/+7
| | | | | | | | | | | | Integrated support for asyncpg's ``terminate()`` method call for cases where the connection pool is recycling a possibly timed-out connection, where a connection is being garbage collected that wasn't gracefully closed, as well as when the connection has been invalidated. This allows asyncpg to abandon the connection without waiting for a response that may incur long timeouts. Fixes: #8419 Change-Id: Ia575af779d5733b483a72dff3690b8bbbad2bb05
* Merge "support create/drop events for all CREATE/DROP" into mainmike bayer2022-08-221-7/+13
|\
| * support create/drop events for all CREATE/DROPMike Bayer2022-08-201-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | Implemented the DDL event hooks :meth:`.DDLEvents.before_create`, :meth:`.DDLEvents.after_create`, :meth:`.DDLEvents.before_drop`, :meth:`.DDLEvents.after_drop` for all :class:`.SchemaItem` objects that include a distinct CREATE or DROP step, when that step is invoked as a distinct SQL statement, including for :class:`.ForeignKeyConstraint`, :class:`.Sequence`, :class:`.Index`, and PostgreSQL's :class:`_postgresql.ENUM`. Fixes: #8394 Change-Id: Iee6274984e794f50103451a04d089641d6ac443a
* | JSONPATH type can be used in casts in PostgreSQLFederico Caselli2022-08-174-21/+49
|/ | | | | | | | | | Introduced the type :class:`_postgresql.JSONPATH` that can be used in cast expressions. This is required by some PostgreSQL dialects when using functions such as ``jsonb_path_exists`` or ``jsonb_path_match`` that accept a ``jsonpath`` as input. Fixes: #8216 Change-Id: I3e7337eab91680cab1604e1f3058854a0a19c5be
* repair doc warningsMike Bayer2022-08-081-1/+1
| | | | | Change-Id: I446105028539a34da90d6b8ae4812965cc398ee5 (cherry picked from commit c539ee35229b03d61f2a10e9f5ab613201341e19)
* Merge "translate joined inheritance cols in UPDATE/DELETE" into mainmike bayer2022-08-051-0/+2
|\
| * translate joined inheritance cols in UPDATE/DELETEMike Bayer2022-08-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue in ORM enabled UPDATE when the statement is created against a joined-inheritance subclass, updating only local table columns, where the "fetch" synchronization strategy would not render the correct RETURNING clause for databases that use RETURNING for fetch synchronization. Also adjusts the strategy used for RETURNING in UPDATE FROM and DELETE FROM statements. Also fixes MariaDB which does not support RETURNING with DELETE..USING. this was not caught in tests because "fetch" strategy wasn't tested. so also adjust the ORMDMLState classes to look for "extra froms" first before adding RETURNING, add new parameters to interfaces for "update_returning_multitable" and "delete_returning_multitable". A new execution option is_delete_using=True, described in the changelog message, is added to allow the ORM to know up front if a certain statement should have a SELECT up front for "fetch" strategy. Fixes: #8344 Change-Id: I3dcdb68e6e97ab0807a573c2fdb3d53c16d063ba
* | credit @zeeeeeb for PG Multirange patchMike Bayer2022-08-051-279/+0
| | | | | | | | | | | | | | | | | | Also move some of the PG docs to the .rst page so we can link to sections. References: #7156 Change-Id: If57abc768d4768058ffa768f9bf72f83c1ee6c29
* | implement PG ranges/multiranges agnosticallyMike Bayer2022-08-057-27/+494
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ranges now work using a new Range object, multiranges as lists of Range objects (this is what asyncpg does. not sure why psycopg has a "Multirange" type). psycopg, psycopg2, and asyncpg are currently supported. It's not clear how to make ranges work with pg8000, likely needs string conversion; this is straightforward with the new archicture and can be added later. Fixes: #8178 Change-Id: Iab8d8382873d5c14199adbe3f09fd0dc17e2b9f1
* | fixes: #7156 - Adds support for PostgreSQL MultiRange typezeeeeb2022-08-043-0/+72
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds functionality for PostgreSQL MultiRange type, as discussed in Issue #7156. As far as I can tell, only psycopg provides a [Multirange adaptation](https://www.psycopg.org/psycopg3/docs/basic/pgtypes.html#multirange-adaptation). Psycopg2 only supports a [Range adaptation/data type](https://www.psycopg.org/psycopg3/docs/basic/pgtypes.html#multirange-adaptation). This pull request is: - [ ] A documentation / typographical error fix - Good to go, no issue or tests are needed - [ ] A short code fix - please include the issue number, and create an issue if none exists, which must include a complete example of the issue. one line code fixes without an issue and demonstration will not be accepted. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. one line code fixes without tests will not be accepted. - [x] A new feature implementation - please include the issue number, and create an issue if none exists, which must include a complete example of how the feature would look. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. Closes: #7816 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7816 Pull-request-sha: 7e9e0c858dcdb58d4fcca24964ef8d58d1842d41 Change-Id: I345e0f58f534ac37709a7a4627b6de8ddd8fa89e
* repair psycopg2 (and psycopg) multiple hosts formatMike Bayer2022-08-013-17/+55
| | | | | | | | | | | | | | | | | | | | | | | | Fixed issue in psycopg2 dialect where the "multiple hosts" feature implemented for :ticket:`4392`, where multiple ``host:port`` pairs could be passed in the query string as ``?host=host1:port1&host=host2:port2&host=host3:port3`` was not implemented correctly, as it did not propagate the "port" parameter appropriately. Connections that didn't use a different "port" likely worked without issue, and connections that had "port" for some of the entries may have incorrectly passed on that hostname. The format is now corrected to pass hosts/ports appropriately. As part of this change, maintained support for another multihost style that worked unintentionally, which is comma-separated ``?host=h1,h2,h3&port=p1,p2,p3``. This format is more consistent with libpq's query-string format, whereas the previous format is inspired by a different aspect of libpq's URI format but is not quite the same thing. If the two styles are mixed together, an error is raised as this is ambiguous. Fixes: #4392 Change-Id: Ic9cc0b0e6e90725e158d9efe73e042853dd1263f
* Reflect expression-based indexes on PostgreSQLFederico Caselli2022-07-282-34/+63
| | | | | | | | | | | The PostgreSQL dialect now supports reflection of expression based indexes. The reflection is supported both when using :meth:`_engine.Inspector.get_indexes` and when reflecting a :class:`_schema.Table` using :paramref:`_schema.Table.autoload_with`. Thanks to immerrr and Aidan Kane for the help on this ticket. Fixes: #7442 Change-Id: I3e36d557235286c0f7f6d8276272ff9225058d48
* Minor cleanupFederico Caselli2022-07-131-5/+0
| | | | | | | - remove unnecessary postgresql visit that's equal to the default compiler - clarify type_annotation_map documentation Change-Id: I0c1fa212d06f6af799a5894802574250622c855e
* document create_engine.isolation_level for PGMike Bayer2022-07-131-6/+9
| | | | | Change-Id: I06eaede9e021eb0790929168e9bedb0c8b58140a References: #8252
* Comments on (named) constraintscheremnov2022-06-291-10/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for comments on named constraints, including `ForeignKeyConstraint`, `PrimaryKeyConstraint`, `CheckConstraint`, `UniqueConstraint`, solving the [Issue 5667](https://github.com/sqlalchemy/sqlalchemy/issues/5667). Supports only PostgreSQL backend. ### Description Following the example of [Issue 1546](https://github.com/sqlalchemy/sqlalchemy/issues/1546), supports comments on constraints. Specifically, enables comments on _named_ ones — as I get it, PostgreSQL prohibits comments on unnamed constraints. Enables setting the comments for named constraints like this: ``` Table( 'example', metadata, Column('id', Integer), Column('data', sa.String(30)), PrimaryKeyConstraint( "id", name="id_pk", comment="id_pk comment" ), CheckConstraint('id < 100', name="cc1", comment="Id value can't exceed 100"), UniqueConstraint(['data'], name="uc1", comment="Must have unique data field"), ) ``` Provides the DDL representation for constraint comments and routines to create and drop them. Class `.Inspector` reflects constraint comments via methods like `get_check_constraints` . ### Checklist <!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once) --> This pull request is: - [ ] A documentation / typographical error fix - [ ] A short code fix - [x] A new feature implementation - Solves the issue 5667. - The commit message includes `Fixes: 5667`. - Includes tests based on comment reflection. **Have a nice day!** Fixes: #5667 Closes: #7742 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7742 Pull-request-sha: 42a5d3c3e9ccf9a9d5397fd007aeab0854f66130 Change-Id: Ia60f578595afdbd6089541c9a00e37997ef78ad3
View Lorry Controller Status