explicitly fetch inserted pk for values(pkcol=None)

Altered the compilation mechanics of the :class:`.Insert` construct such
that the "autoincrement primary key" column value will be fetched via
``cursor.lastrowid`` or RETURNING even if present in the parameter set or
within the :meth:`.Insert.values` method as a plain bound value, for
single-row INSERT statements on specific backends that are known to
generate autoincrementing values even when explicit NULL is passed. This
restores a behavior that was in the 1.3 series for both the use case of
separate parameter set as well as :meth:`.Insert.values`. In 1.4, the
parameter set behavior unintentionally changed to no longer do this, but
the :meth:`.Insert.values` method would still fetch autoincrement values up
until 1.4.21 where :ticket:`6770` changed the behavior yet again again
unintentionally as this use case was never covered.

The behavior is now defined as "working" to suit the case where databases
such as SQLite, MySQL and MariaDB will ignore an explicit NULL primary key
value and nonetheless invoke an autoincrement generator.

Fixes: #7998
Change-Id: I5d4105a14217945f87fbe9a6f2a3c87f6ef20529

1 files changed, 51 insertions, 0 deletions

diff --git a/test/sql/test_insert.py b/test/sql/test_insert.py
index 5f02fde4c..2f9f9a4f7 100644
--- a/test/sql/test_insert.py
+++ b/test/sql/test_insert.py
@@ -943,6 +943,57 @@ class InsertImplicitReturningTest(
             checkparams={"name_1": "foo"},
         )
 
+    @testing.combinations(
+        True, False, argnames="insert_null_still_autoincrements"
+    )
+    @testing.combinations("values", "params", "nothing", argnames="paramtype")
+    def test_explicit_null_implicit_returning_still_renders(
+        self, paramtype, insert_null_still_autoincrements
+    ):
+        """test for future support of #7998 with RETURNING"""
+        t = Table(
+            "t",
+            MetaData(),
+            Column("x", Integer, primary_key=True),
+            Column("q", Integer),
+        )
+
+        dialect = postgresql.dialect(implicit_returning=True)
+        dialect.insert_null_pk_still_autoincrements = (
+            insert_null_still_autoincrements
+        )
+
+        if paramtype == "values":
+            # for values present, we now have an extra check for this
+            stmt = t.insert().values(x=None, q=5)
+            if insert_null_still_autoincrements:
+                expected = (
+                    "INSERT INTO t (x, q) VALUES (%(x)s, %(q)s) RETURNING t.x"
+                )
+            else:
+                expected = "INSERT INTO t (x, q) VALUES (%(x)s, %(q)s)"
+            params = None
+        elif paramtype == "params":
+            # for params, compiler doesnt have the value available to look
+            # at.  we assume non-NULL
+            stmt = t.insert()
+            if insert_null_still_autoincrements:
+                expected = (
+                    "INSERT INTO t (x, q) VALUES (%(x)s, %(q)s) RETURNING t.x"
+                )
+            else:
+                expected = "INSERT INTO t (x, q) VALUES (%(x)s, %(q)s)"
+            params = {"x": None, "q": 5}
+        elif paramtype == "nothing":
+            # no params, we assume full INSERT.  this kind of compilation
+            # doesn't actually happen during execution since there are always
+            # parameters or values
+            stmt = t.insert()
+            expected = "INSERT INTO t (x, q) VALUES (%(x)s, %(q)s)"
+            params = None
+
+        self.assert_compile(stmt, expected, params=params, dialect=dialect)
+
     def test_insert_multiple_values(self):
         ins = self.tables.myothertable.insert().values(
             [{"othername": "foo"}, {"othername": "bar"}]