From: Mike Bayer <mike_mp@zzzcomputing.com>
Date: Tue, 3 Jan 2023 19:54:14 +0000 (-0500)
Subject: changelog updates
X-Git-Tag: rel_1_4_46~2
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f26207c7307f3449e0235a264db0fcf5b089ff73;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git

changelog updates

Change-Id: I69581c1563f15762a9a9afae4741e23fefd76906
---

diff --git a/doc/build/changelog/unreleased_14/8983.rst b/doc/build/changelog/unreleased_14/8983.rst
new file mode 100644
index 0000000000..bfea2ea2a5
--- /dev/null
+++ b/doc/build/changelog/unreleased_14/8983.rst
@@ -0,0 +1,17 @@
+.. change::
+    :tags: change, general
+    :tickets: 8983
+
+    A new deprecation "uber warning" is now emitted at once at runtime, the
+    first time any SQLAlchemy 2.0 deprecation warning would normally be
+    emitted, but the ``SQLALCHEMY_WARN_20`` environment variable is not set.
+    This deprecation warning intends to notify users who may not have set an
+    appropriate constraint in their requirements files to block against a
+    surprise SQLAlchemy 2.0 upgrade and also alert that the SQLAlchemy 2.0
+    upgrade process is available, as the first full 2.0 release is expected
+    very soon. The deprecation warning can be silenced by setting the
+    environment variable ``SQLALCHEMY_SILENCE_UBER_WARNING`` to ``"1"``.
+
+    .. seealso::
+
+        :ref:`migration_20_toplevel`
diff --git a/doc/build/changelog/unreleased_14/8989.rst b/doc/build/changelog/unreleased_14/8989.rst
index 4c38fdf019..2287bec7b4 100644
--- a/doc/build/changelog/unreleased_14/8989.rst
+++ b/doc/build/changelog/unreleased_14/8989.rst
@@ -1,5 +1,5 @@
 .. change::
-    :tags: bug, types
+    :tags: bug, sql
     :tickets: 8989
     :versions: 2.0.0b5
 
diff --git a/doc/build/changelog/unreleased_14/9023.rst b/doc/build/changelog/unreleased_14/9023.rst
index 3bbbd0f3fb..8a2d0b9ca3 100644
--- a/doc/build/changelog/unreleased_14/9023.rst
+++ b/doc/build/changelog/unreleased_14/9023.rst
@@ -4,10 +4,10 @@
     :versions: 2.0.0rc1
 
     Fixed bug where the PostgreSQL
-    :paramref:`_postgresql.OnConflictClause.constraint` parameter would accept
-    an :class:`.Index` object, however would not expand this index out into its
-    individual index expressions, instead rendering its name in an ON CONFLICT
-    ON CONSTRAINT clause, which is not accepted by PostgreSQL; the "constraint
-    name" form only accepts unique or exclude constraint names. The parameter
-    continues to accept the index but now expands it out into its component
-    expressions for the render.
+    :paramref:`_postgresql.Insert.on_conflict_do_update.constraint` parameter
+    would accept an :class:`.Index` object, however would not expand this index
+    out into its individual index expressions, instead rendering its name in an
+    ON CONFLICT ON CONSTRAINT clause, which is not accepted by PostgreSQL; the
+    "constraint name" form only accepts unique or exclude constraint names. The
+    parameter continues to accept the index but now expands it out into its
+    component expressions for the render.