Added support for ``psycopg`` dialect.

Both sync and async versions are supported.

Fixes: #6842
Change-Id: I57751c5028acebfc6f9c43572562405453a2f2a4

Merge "propose emulated setinputsizes embedded in the compiler" into main

Merge "Clean up most py3k compat" into main

Clean up most py3k compat

Change-Id: I8172fdcc3103ff92aa049827728484c8779af6b7

Try fixing ``ORMExecuteState`` again.

follow up of 7c3d3670c68298e88d03bc8f02e01c6a3f7fe42f

Change-Id: I3e9b7ab458677efcf47256103543fcc6db2a3076

Improve ``ORMExecuteState`` documentation

propose emulated setinputsizes embedded in the compiler

Add a new system so that PostgreSQL and other dialects have a
reliable way to add casts to bound parameters in SQL statements,
replacing previous use of setinputsizes() for PG dialects.

rationale:

1. psycopg3 will be using the same SQLAlchemy-side "setinputsizes"
   as asyncpg, so we will be seeing a lot more of this

2. the full rendering that SQLAlchemy's compilation is performing
   is in the engine log as well as error messages.   Without this,
   we introduce three levels of SQL rendering, the compiler, the
   hidden "setinputsizes" in SQLAlchemy, and then whatever the DBAPI
   driver does.  With this new approach, users reporting bugs etc.
   will be less confused that there are as many as two separate
   layers of "hidden rendering"; SQLAlchemy's rendering is again
   fully transparent

3. calling upon a setinputsizes() method for every statement execution
   is expensive.  this way, the work is done behind the caching layer

4. for "fast insertmany()", I also want there to be a fast approach
   towards setinputsizes.  As it was, we were going to be taking
   a SQL INSERT with thousands of bound parameter placeholders and
   running a whole second pass on it to apply typecasts.    this way,
   we will at least be able to build the SQL string once without a huge
   second pass over the whole string

5. psycopg2 can use this same system for its ARRAY casts

6. the general need for PostgreSQL to have lots of type casts
   is now mostly in the base PostgreSQL dialect and works independently
   of a DBAPI being present.   dependence on DBAPI symbols that aren't
   complete / consistent / hashable is removed

I was originally going to try to build this into bind_expression(),
but it was revealed this worked poorly with custom bind_expression()
as well as empty sets.   the current impl also doesn't need to
run a second expression pass over the POSTCOMPILE sections, which
came out better than I originally thought it would.

Change-Id: I363e6d593d059add7bcc6d1f6c3f91dd2e683c0c

Support lightweight compiler column elements w/ slots

the _CompileLabel class included ``__slots__`` but these
weren't used as the superclasses included slots.

Create a ``__slots__`` superclass for ``ClauseElement``,
creating a new class of compilable SQL elements that don't
include heavier features like caching, annotations and
cloning, which are meant to be used only in an ad-hoc
compiler fashion.   Create new ``CompilerColumnElement``
from that which serves in column-oriented contexts, but
similarly does not include any expression operator support
as it is intended to be used only to generate a string.

Apply this to both
``_CompileLabel`` as well as PostgreSQL ``_ColonCast``,
which does not actually subclass ``ColumnElement`` as this
class has memoized attributes that aren't worth changing,
and does not include SQL operator capabilities as these
are not needed for these compiler-only objects.

this allows us to more inexpensively add new ad-hoc
labels / casts etc. at compile time, as we will be seeking
to expand out the typecasts that are needed for PostgreSQL
dialects in a subsequent patch.

Change-Id: I52973ae3295cb6e2eb0d7adc816c678a626643ed

Remove object in class definition

References: #4600
Change-Id: I2a62ddfe00bc562720f0eae700a497495d7a987a

provide space for new 2.0 changes not part of upgrade path

As we are going to be adding new improvements such as
variant, cython, psycopg3, more RETURNING support,
fast execution helpers, and probably a lot more, the
2.0 migration doc needs to also still have the "what's new in 2.0?"
thing going on as well.   Organize the document so it has space
to introduce these sections, as well as the existing
1.4->2.0 migration sections.

If the "What's New" document gets large, we will break up this
page into two separate pages, it's already quite large, so
the proposal would be the exising migration doc becomes
a separate special migration document.

Change-Id: I62496b30229806f4a82d1f92b3f4eda53e64df57

fix year

Change-Id: I56a325fde167501a53b588cc1b69255238ac1dbb

Merge "favor setuptools imports over distutils" into main

Merge "generalize cache_ok to UserDefinedType" into main

Merge "disable raiseerr for refresh state loader options" into main

Merge "use typing.Dict" into main

Merge "fully support isolation_level parameter in base dialect" into main

use typing.Dict

newer Pythons seem to accept ``dict[Any, Any]`` which is why
this wasn't noticed.  Revise fix for #7321 made in
I55656e867876677c5c55143449db371344be8600.

Fixes: #7321
Change-Id: Idc22e15d098543e07853f4532cfd1aaae4dd6404

fully support isolation_level parameter in base dialect

Generalized the :paramref:`_sa.create_engine.isolation_level` parameter to
the base dialect so that it is no longer dependent on individual dialects
to be present. This parameter sets up the "isolation level" setting to
occur for all new database connections as soon as they are created by the
connection pool, where the value then stays set without being reset on
every checkin.

The :paramref:`_sa.create_engine.isolation_level` parameter is essentially
equivalent in functionality to using the
:paramref:`_engine.Engine.execution_options.isolation_level` parameter via
:meth:`_engine.Engine.execution_options` for an engine-wide setting. The
difference is in that the former setting assigns the isolation level just
once when a connection is created, the latter sets and resets the given
level on each connection checkout.

Fixes: #6342
Change-Id: Id81d6b1c1a94371d901ada728a610696e09e9741

disable raiseerr for refresh state loader options

Fixed ORM regression where the new behavior of "eager loaders run on
unexpire" added in :ticket:`1763` would lead to loader option errors being
raised inappropriately for the case where a single :class:`_orm.Query` or
:class:`_sql.Select` were used to load multiple kinds of entities, along
with loader options that apply to just one of those kinds of entity like a
:func:`_orm.joinedload`, and later the objects would be refreshed from
expiration, where the loader options would attempt to be applied to the
mismatched object type and then raise an exception. The check for this
mismatch now bypasses raising an error for this case.

Fixes: #7318
Change-Id: I111e0f3e0fb0447355574cbdcde002f734833490

Merge "remove "native decimal" warning" into main

Merge "Add new sections regarding schemas and reflection" into main

Merge "handle dunder names in @declared_attr separately" into main

Merge "Deprecate create_engine.implicit_returning" into main

remove "native decimal" warning

Removed the warning that emits from the :class:`_types.Numeric` type about
DBAPIs not supporting Decimal values natively. This warning was oriented
towards SQLite, which does not have any real way without additional
extensions or workarounds of handling precision numeric values more than 15
significant digits as it only uses floating point math to represent
numbers. As this is a known and documented limitation in SQLite itself, and
not a quirk of the pysqlite driver, there's no need for SQLAlchemy to warn
for this. The change does not otherwise modify how precision numerics are
handled. Values can continue to be handled as ``Decimal()`` or ``float()``
as configured with the :class:`_types.Numeric`, :class:`_types.Float` , and
related datatypes, just without the ability to maintain precision beyond 15
significant digits when using SQLite, unless alternate representations such
as strings are used.

Fixes: #7299
Change-Id: Ic570f8107177dec3ddbe94c7b43f40057b03276a

favor setuptools imports over distutils

Python 3.10 has deprecated "distutils" in favor of explicit use of
"setuptools" in :pep:`632`; SQLAlchemy's setup.py has replaced imports
accordingly. However, since setuptools itself only recently added the
replacement symbols mentioned in pep-632 as of November of 2022 in version
59.0.1, ``setup.py`` still has fallback imports to distutils, as SQLAlchemy
1.4 does not have a hard setuptools versioning requirement at this time.
SQLAlchemy 2.0 is expected to use a full :pep:`517` installation layout
which will indicate appropriate setuptools versioning up front.

Fixes: #7311
Change-Id: I215ef3c3b226a38266f59d181214aea462c4664d

handle dunder names in @declared_attr separately

Fixed Mypy crash which would occur when using Mypy plugin against code
which made use of :class:`_orm.declared_attr` methods for non-mapped names
like ``__mapper_args__``, ``__table_args__``, or other dunder names, as the
plugin would try to interpret these as mapped attributes which would then
be later mis-handled. As part of this change, the decorated function is
still converted by the plugin into a generic assignment statement (e.g.
``__mapper_args__: Any``) so that the argument signature can continue to be
annotated in the same way one would for any other ``@classmethod`` without
Mypy complaining about the wrong argument type for a method that isn't
explicitly ``@classmethod``.

Fixes: #7321
Change-Id: I55656e867876677c5c55143449db371344be8600

Add new sections regarding schemas and reflection

* add a new section to reflection.rst `Schemas and Reflection`.
  * this contains some text from the ticket
* migrate some text from `Specifying the Schema Name` to new section
* migrate some text from PostgreSQL dialect to new section
  * target text is made more generic
  * cross-reference the postgres and new sections to one another, to avoid duplication of docs
* update some docs 'meta' to 'metadata_obj'

Fixes: #4387
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: I2b08672753fb2575d30ada07ead77587468fdade

generalize cache_ok to UserDefinedType

Extended the ``cache_ok`` flag and corresponding warning message if this
flag is not defined, a behavior first established for
:class:`.TypeDecorator` as part of :ticket:`6436`, to also take place for
:class:`.UserDefinedType`, by generalizing the flag and associated caching
logic to a new common base for these two types, :class:`.ExternalType`.

The change means any current :class:`.UserDefinedType` will now cause SQL
statement caching to no longer take place for statements which make use of
the datatype, along with a warning being emitted, unless the class defines
the :attr:`.UserDefinedType.cache_ok` flag as True. If the datatype cannot
form a deterministic, hashable cache key derived from its arguments, it may return
False which will continue to keep caching disabled but will suppress the
warning. In particular, custom datatypes currently used in packages such as
SQLAlchemy-utils will need to implement this flag. The issue was observed
as a result of a SQLAlchemy-utils datatype that is not currently cacheable.

Fixes: #7319
Change-Id: Ie0b5d4587df87bfe66d2fe7cd4585c3882584575

Add Non linear CTE support

"Compound select" methods like :meth:`_sql.Select.union`,
:meth:`_sql.Select.intersect_all` etc. now accept ``*other`` as an argument
rather than ``other`` to allow for multiple additional SELECTs to be
compounded with the parent statement at once. In particular, the change as
applied to :meth:`_sql.CTE.union` and :meth:`_sql.CTE.union_all` now allow
for a so-called "non-linear CTE" to be created with the :class:`_sql.CTE`
construct, whereas previously there was no way to have more than two CTE
sub-elements in a UNION together while still correctly calling upon the CTE
in recursive fashion. Pull request courtesy Eric Masseran.

Allow:

```sql
WITH RECURSIVE nodes(x) AS (
   SELECT 59
   UNION
   SELECT aa FROM edge JOIN nodes ON bb=x
   UNION
   SELECT bb FROM edge JOIN nodes ON aa=x
)
SELECT x FROM nodes;
```

Based on @zzzeek suggestion: https://github.com/sqlalchemy/sqlalchemy/pull/7133#issuecomment-933882348

Fixes: #7259
Closes: #7260
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7260
Pull-request-sha: 2565a5fd4b1940e92125e53aeaa731cc682f49bb

Change-Id: I685c8379762b5fb6ab4107ff8f4d8a4de70c0ca6

pass through docs for 2.0 style

this change restores the orm/tutorial.rst and
core/tutorial.rst files, hidden from the index with
an update on the new tutorial.

Also started noting Query is legacy, as we will have
lots of docs to update for 2.0 style.

Change-Id: I4f98eeaaa0fd6e03b9976320b568975fe6d06ade

cherry-pick changelog update for 1.4.28

cherry-pick changelog from 1.4.27

Merge "removals: all unicode encoding / decoding" into main

removals: all unicode encoding / decoding

Removed here includes:

* convert_unicode parameters
* encoding create_engine() parameter
* description encoding support
* "non-unicode fallback" modes under Python 2
* String symbols regarding Python 2 non-unicode fallbacks
* any concept of DBAPIs that don't accept unicode
  statements, unicode bound parameters, or that return bytes
  for strings anywhere except an explicit Binary / BLOB
  type
* unicode processors in Python / C

Risk factors:

* Whether all DBAPIs do in fact return Unicode objects for
  all entries in cursor.description now
* There was logic for mysql-connector trying to determine
  description encoding.   A quick test shows Unicode coming
  back but it's not clear if there are still edge cases where
  they return bytes.  if so, these are bugs in that driver,
  and at most we would only work around it in the mysql-connector
  DBAPI itself (but we won't do that either).
* It seems like Oracle 8 was not expecting unicode bound parameters.
  I'm assuming this was all Python 2 stuff and does not apply
  for modern cx_Oracle under Python 3.
* third party dialects relying upon built in unicode encoding/decoding
  but it's hard to imagine any non-SQLAlchemy database driver not
  dealing exclusively in Python unicode strings in Python 3

Change-Id: I97d762ef6d4dd836487b714d57d8136d0310f28a
References: #7257

qualify asyncpg API tests for python 3.8

Getting
TypeError: object MagicMock can't be used in 'await' expression
for Python 3.7 and earlier.  this test is not needed
on all platforms it's confirming that two methods
are present.

Change-Id: If918add023c98c062ea0c1cd132a999647a2d35f

Merge "set within_columns_clause=False for all sub-elements of select()" into main

Merge "upgrade deferred loader to regular loader if refresh_state" into main

Merge "change the POSTCOMPILE/ SCHEMA symbols to not conflict w mssql quoting" into main

Merge "Fixes: #7295" into main

change the POSTCOMPILE/ SCHEMA symbols to not conflict w mssql quoting

Adjusted the compiler's generation of "post compile" symbols including
those used for "expanding IN" as well as for the "schema translate map" to
not be based directly on plain bracketed strings with underscores, as this
conflicts directly with SQL Server's quoting format of also using brackets,
which produces false matches when the compiler replaces "post compile" and
"schema translate" symbols. The issue created easy to reproduce examples
both with the :meth:`.Inspector.get_schema_names` method when used in
conjunction with the
:paramref:`_engine.Connection.execution_options.schema_translate_map`
feature, as well in the unlikely case that a symbol overlapping with the
internal name "POSTCOMPILE" would be used with a feature like "expanding
in".

Fixes: #7300
Change-Id: I6255c850b140522a4aba95085216d0bca18ce230

set within_columns_clause=False for all sub-elements of select()

Fixed issue where using the feature of using a string label for ordering or
grouping described at :ref:`tutorial_order_by_label` would fail to function
correctly if used on a :class:`.CTE` construct, when the CTE were embedded
inside of an enclosing :class:`_sql.Select` statement that itself was set
up as a scalar subquery.

Fixes: #7269
Change-Id: Ied6048a1c9a622374a418230c8cfedafa8d3f87e

revert mis-commit from aa026c302c6b188a7e28508f9ecb603809b9e03f

A scratch line from #7269 was inadvertently committed here.
this needs to be in its own commit w/ tests.

Change-Id: I62796e18b05bbbd3b6225e9f27e1e63ab98cf24c

upgrade deferred loader to regular loader if refresh_state

Fixed issue where deferred polymorphic loading of attributes from a
joined-table inheritance subclass would fail to populate the attribute
correctly if the :func:`_orm.load_only` option were used to originally
exclude that attribute, in the case where the load_only were descending
from a relationship loader option.  The fix allows that other valid options
such as ``defer(..., raiseload=True)`` etc. still function as expected.

Fixes: #7304
Change-Id: I58b7ce7c450bcc52d2f0c9bfbcb4d747463ee9b2

Deprecate create_engine.implicit_returning

The :paramref:`_sa.create_engine.implicit_returning` parameter is
deprecated on the :func:`_sa.create_engine` function only; the parameter
remains available on the :class:`_schema.Table` object. This parameter was
originally intended to enable the "implicit returning" feature of
SQLAlchemy when it was first developed and was not enabled by default.
Under modern use, there's no reason this parameter should be disabled, and
it has been observed to cause confusion as it degrades performance and
makes it more difficult for the ORM to retrieve recently inserted server
defaults. The parameter remains available on :class:`_schema.Table` to
specifically suit database-level edge cases which make RETURNING
infeasible, the sole example currently being SQL Server's limitation that
INSERT RETURNING may not be used on a table that has INSERT triggers on it.

Also removed from the Oracle dialect some logic that would upgrade
an Oracle 8/8i server version to use implicit returning if the
parameter were explictly passed; these versions of Oracle
still support RETURNING so the feature is now enabled for all
Oracle versions.

Fixes: #6962
Change-Id: Ib338e300cd7c8026c3083043f645084a8211aed8

De-emphasize notion of "default driver" (DBAPI)

Fixes: #6960
Even though a default driver still exists for
each dialect, remove most usages of `dialect://`
to encourage users to explicitly specify
`dialect+driver://`

Change-Id: I0ad42167582df509138fca64996bbb53e379b1af

connection doc updates for future

* remove autocommit section, missed in future engine merge
* remove implicit execution section, also missed
* rewrite "transactions" section to fully discuss
  "commit as you go" vs. "begin once", remove all references
  to "future"
* fix up "understanding DBAPI autocommit" to be a little more
  clear

Pushing this straight up, we can attend to remaining typos /
edits ad hoc

Change-Id: I687c89a515e5a5cdce69700b039bb7c10d90159a

Merge "fully implement future engine and remove legacy" into main

fully implement future engine and remove legacy

The major action here is to lift and move future.Connection
and future.Engine fully into sqlalchemy.engine.base.   This
removes lots of engine concepts, including:

* autocommit
* Connection running without a transaction, autobegin
  is now present in all cases
* most "autorollback" is obsolete
* Core-level subtransactions (i.e. MarkerTransaction)
* "branched" connections, copies of connections
* execution_options() returns self, not a new connection
* old argument formats, distill_params(), simplifies calling
  scheme between engine methods
* before/after_execute() events (oriented towards compiled constructs)
  don't emit for exec_driver_sql().  before/after_cursor_execute()
  is still included for this
* old helper methods superseded by context managers, connection.transaction(),
  engine.transaction() engine.run_callable()
* ancient engine-level reflection methods has_table(), table_names()
* sqlalchemy.testing.engines.proxying_engine

References: #7257

Change-Id: Ib20ed816642d873b84221378a9ec34480e01e82c

Fixes: #7295
Fixed issue in ``Table``` object where: param:`implicit_returning` was not
compatible with: param:`extend_existing`.
Change-Id: I16f4ab585d82f5691a3fed9eba04b84730a8a59e

Merge "use tuple expansion if type._is_tuple, test for Sequence if no type" into main

use tuple expansion if type._is_tuple, test for Sequence if no type

Fixed regression where the row objects returned for ORM queries, which are
now the normal :class:`_sql.Row` objects, would not be interpreted by the
:meth:`_sql.ColumnOperators.in_` operator as tuple values to be broken out
into individual bound parameters, and would instead pass them as single
values to the driver leading to failures. The change to the "expanding IN"
system now accommodates for the expression already being of type
:class:`.TupleType` and treats values accordingly if so. In the uncommon
case of using "tuple-in" with an untyped statement such as a textual
statement with no typing information, a tuple value is detected for values
that implement ``collections.abc.Sequence``, but that are not ``str`` or
``bytes``, as always when testing for ``Sequence``.

Added :class:`.TupleType` to the top level ``sqlalchemy`` import namespace.

Fixes: #7292
Change-Id: I8286387e3b3c3752b3bd4ae3560d4f31172acc22

fix typo in changelog.

Change-Id: Ic78a9ce9032ab759fc796d3218b64352dde6155b

Check for Mapping explicitly in 2.0 params

Fixed issue in future :class:`_future.Connection` object where the
:meth:`_future.Connection.execute` method would not accept a non-dict
mapping object, such as SQLAlchemy's own :class:`.RowMapping` or other
``abc.collections.Mapping`` object as a parameter dictionary.

Fixes: #7291
Change-Id: I819f079d86d19d1d81c570e0680f987e51e34b84

Update "transaction has already begun" language

As future connections will now be autobeginning, there
will be more cases where begin() can't be called as well as where isolation level
can't be set, which will be surprising as this is a behavioral
change for 2.0; additionally, when DBAPI autocommit is set,
there isn't actually a DBAPI level transaction in effect even though
Connection has a Transaction object.  Clarify the language in these
two error messages to make it clear that begin() and autobegin
are tracking a SQLAlchemy-level Transaction() object, whether or not
the DBAPI has actually started a transaction, and that this is the
reason rollback() or commit() is required before performing
the requsted operation.   Additionally make sure the error message
mentions "autobegin" as a likely reason this error is being
encountered along with what Connection needs the user to do in
order to resolve.

Change-Id: If8763939eeabc46aa9d9209a56d05ad82b892c5c

Merge "simplify and publicize the asyncpg JSON(B) codec registrsation" into main

simplify and publicize the asyncpg JSON(B) codec registrsation

Added overridable methods ``PGDialect_asyncpg.setup_asyncpg_json_codec``
and ``PGDialect_asyncpg.setup_asyncpg_jsonb_codec`` codec, which handle the
required task of registering JSON/JSONB codecs for these datatypes when
using asyncpg. The change is that methods are broken out as individual,
overridable methods to support third party dialects that need to alter or
disable how these particular codecs are set up.

Fixes: #7284
Change-Id: I3eac258fea61f3975bd03c428747f788813ce45e

use ExpressionElementRole for case targets in case()

Fixed regression where the :func:`_sql.text` construct would no longer be
accepted as a target case in the "whens" list within a :func:`_sql.case`
construct. The regression appears related to an attempt to guard against
some forms of literal values that were considered to be ambiguous when
passed here; however, there's no reason the target cases shouldn't be
interpreted as open-ended SQL expressions just like anywhere else, and a
literal string or tuple will be converted to a bound parameter as would be
the case elsewhere.

Fixes: #7287
Change-Id: I75478adfa115f3292cb1362cc5b2fdf152b0ed6f

add missing info from groupby documentation

Change-Id: Icfaf242353c23a579fe79f9d72500a08d90fcb77
Signed-off-by: Federico Caselli <cfederico87@gmail.com>

Revert "Gracefully degrade unsupported types with asyncpg"

This reverts commit 96c294da8a50d692b3f0b8e508dbbca5d9c22f1b.

I have another approach that is more obvious, easier to override explicitly and also I can test it more easily.

Change-Id: I11a3be7700dbc6f25d436e450b6fb8e8f6c4fd16

formatting updates

Change-Id: I7352bed0115b8fcdb4708e012d83e81d1ae494ed

Merge "Gracefully degrade unsupported types with asyncpg" into main

Merge "Fixed issue in visit_on_duplicate_key_update within a composed expression" into main

Fixed issue in visit_on_duplicate_key_update within a composed expression

Fixed issue in MySQL :meth:`_mysql.Insert.on_duplicate_key_update` which
would render the wrong column name when an expression were used in a VALUES
expression. Pull request courtesy Cristian Sabaila.

Fixes: #7281
Closes: #7285
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7285
Pull-request-sha: 3e6ad6f2fecc6ae36a10a5a34b5d3d393483edbb

Change-Id: I83377c20eae6358fead9e7e361127938e538a71c

map Float to asyncpg.FLOAT, test for infinity

Fixes: #7283
Change-Id: I5402a72617b7f9bc366d64bc5ce8669374839984

Gracefully degrade unsupported types with asyncpg

Fixes: #7284
Modify the on_connect() method of PGDialect_asyncpg to
gracefully degrade unsupported types instead of throwing a
ValueError. Useful for third-party dialects that derive
from PGDialect_asyncpg but whose databases do not support
all types (e.g., CockroachDB supports JSONB but not JSON).

Change-Id: Ibb7cc8c3de632d27b9716a93d83956a590b2a2b0

Merge "ensure soft_close occurs for fetchmany with server side cursor" into main

Merge "First round of removal of python 2" into main

ensure soft_close occurs for fetchmany with server side cursor

Fixed regression where the :meth:`_engine.CursorResult.fetchmany` method
would fail to autoclose a server-side cursor (i.e. when ``stream_results``
or ``yield_per`` is in use, either Core or ORM oriented results) when the
results were fully exhausted.

All :class:`_result.Result` objects will now consistently raise
:class:`_exc.ResourceClosedError` if they are used after a hard close,
which includes the "hard close" that occurs after calling "single row or
value" methods like :meth:`_result.Result.first` and
:meth:`_result.Result.scalar`. This was already the behavior of the most
common class of result objects returned for Core statement executions, i.e.
those based on :class:`_engine.CursorResult`, so this behavior is not new.
However, the change has been extended to properly accommodate for the ORM
"filtering" result objects returned when using 2.0 style ORM queries,
which would previously behave in "soft closed" style of returning empty
results, or wouldn't actually "soft close" at all and would continue
yielding from the underlying cursor.

As part of this change, also added :meth:`_result.Result.close` to the base
:class:`_result.Result` class and implemented it for the filtered result
implementations that are used by the ORM, so that it is possible to call
the :meth:`_engine.CursorResult.close` method on the underlying
:class:`_engine.CursorResult` when the the ``yield_per`` execution option
is in use to close a server side cursor before remaining ORM results have
been fetched. This was again already available for Core result sets but the
change makes it available for 2.0 style ORM results as well.

Fixes: #7274
Change-Id: Id4acdfedbcab891582a7f8edd2e2e7d20d868e53

Fixes: #7278
Correct a typo in the 1.4 changelog

Change-Id: Ib7d1fc75957ad2efb348fee9d862d75b06dbafef

use full context manager flow for future.Engine.begin()

Fixed issue in future :class:`_future.Engine` where calling upon
:meth:`_future.Engine.begin` and entering the context manager would not
close the connection if the actual BEGIN operation failed for some reason,
such as an event handler raising an exception; this use case failed to be
tested for the future version of the engine. Note that the "future" context
managers which handle ``begin()`` blocks in Core and ORM don't actually run
the "BEGIN" operation until the context managers are actually entered. This
is different from the legacy version which runs the "BEGIN" operation up
front.

Fixes: #7272
Change-Id: I9667ac0861a9e007c4b3dfcf0fcf0829038a8711

First round of removal of python 2

References: #4600
Change-Id: I61e35bc93fe95610ae75b31c18a3282558cd4ffe

Merge "remove case_sensitive create_engine parameter" into main

remove case_sensitive create_engine parameter

Removed the previously deprecated ``case_sensitive`` parameter from
:func:`_sa.create_engine`, which would impact only the lookup of string
column names in Core-only result set rows; it had no effect on the behavior
of the ORM. The effective behavior of what ``case_sensitive`` refers
towards remains at its default value of ``True``, meaning that string names
looked up in ``row._mapping`` will match case-sensitively, just like any
other Python mapping.

Change-Id: I0dc4be3fac37d30202b1603db26fa10a110b618d

de-link LegacyRow, LegacyCursorResult

Change-Id: I4a9d210c3cb07fc1d59643463acef95f9cc9b12e

Merge "Update psycopg2 dialect to use the DBAPI interface to execute two phase transactions" into main

Revise "literal parameters" FAQ section

based on feedback in #7271, the emphasis on TypeDecorator
as a solution to this problem is not very practical.  illustrate
a series of quick recipes that are useful for debugging purposes
to print out a repr() or simple stringify of a parameter
without the need to construct custom dialects or types.

Change-Id: I788ce1b5ea01d88dd0a22d03d06f35aabff5e5c8

Merge "2.0 removals: LegacyRow, connectionless execution, close_with_result" into main

2.0 removals: LegacyRow, connectionless execution, close_with_result

in order to remove LegacyRow / LegacyResult, we have
to also lose close_with_result, which connectionless
execution relies upon.

also includes a new profiles.txt file that's all against
py310, as that's what CI is on now.  some result counts
changed by one function call which was enough to fail the
low-count result tests.

Replaces Connectable as the common interface between
Connection and Engine with EngineEventsTarget.  Engine
is no longer Connectable.  Connection and MockConnection
still are.

References: #7257
Change-Id: Iad5eba0313836d347e65490349a22b061356896a

Update psycopg2 dialect to use the DBAPI interface to execute
two phase transactions

Fixes: #7238
Change-Id: Ie4f5cf59d29b5bfc142ec2dfdecffb896ee7d708

Merge "Remove deprecated dialects and drivers" into main

Remove deprecated dialects and drivers

Fixes: #7258
Change-Id: I3577f665eca04f2632b69bcb090f0a4ec9271db9

The ``has_table`` method now also checks views

The :meth:`_engine.Inspector.has_table` method will now consistently check
for views of the given name as well as tables. Previously this behavior was
dialect dependent, with PostgreSQL, MySQL/MariaDB and SQLite supporting it,
and Oracle and SQL Server not supporting it. Third party dialects should
also seek to ensure their :meth:`_engine.Inspector.has_table` method
searches for views as well as tables for the given name.

Fixes: #7161
Change-Id: I9e523c76741b19596c81ef577dc6f0823e44183b

remove ORM autocommit and public-facing subtransactions concept

In order to do LegacyRow we have to do Connection, which means
we lose close_with_result (hooray) which then means we
have to get rid of ORM session autocommit which relies on it, so
let's do that first.

Change-Id: I115f614733b1d0ba19f320ffa9a49f0d762db094

Merge "initial 2.0 setup" into main

remove python2 from workflows

Change-Id: Ib2da811acbad291dc9bbe798c84f2309f5d0f21e

initial 2.0 setup

Adapted from 55e64f857daeb6057b85ff67297a774b when we
previously started a 2.0 branch.

Change-Id: Ib5af75df94b23104eebe0e918adcf979d798ea3b

warnings removal, merge_result

this is the last warning to remove.

Also fixes some mistakes I made with the new
Base20DeprecationWarning and LegacyAPIWarning classes created,
where functions in deprecations.py were still hardcoded to
RemovedIn20Warning.

Change-Id: I9a6045ac9b813fd2f9668c4bc518c46a7774c6ef

Merge "warnings: session.autocommit, subtransactions" into main

clarify order_by(None) for Core; improve wording

the order_by(None) convention was documented for orm.Query
but not Core select.

Change-Id: I0c1ad76c3eefba1cb54b1649cfd09169c17e2bba

warnings: session.autocommit, subtransactions

Change-Id: I7eb7c87c9656f8043ea90d53897958afad2b8fe9

warnings: with_polymorphic()

Also clarifies a behavior of None/False for the selectable
parameter to with_polymorphic()

Fixes: #7262
Change-Id: I58c4004e0af227d3995e9ae2461470440f97f252

Merge "Modernize tests - session_query_get" into main

Modernize tests - session_query_get

Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: I92013aad471baf32df1b51b756e86d95449b5cfd

warnings: cascade_backrefs

this one is a little different in that the thing changing
is the detection of a behavior, not an explicit API.

Change-Id: Id142943a2b901b39fe9053d0120c1e820dc1a6d0

Merge "Improve array support on pg8000" into main

Improve array support on pg8000

References: #6023

Change-Id: I0f6cbc34b3c0bfc0b8c86b3ebe4531e23039b6c0

Merge "deprecation warnings: with_parent, aliased, from_joinpoint" into main

Merge "consider "inspect(_of_type)" to be the entity of a comparator" into main

deprecation warnings: with_parent, aliased, from_joinpoint

most of the work for aliased / from_joinpoint has been done
already as I added all new tests for these and moved
most aliased/from_joinpoint to test/orm/test_deprecations.py
already

Change-Id: Ia23e332dec183de17b2fb9d89d946af8d5e89ae7

Merge "Fixes: #5020" into main