id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
36392	ValueError not raised when wrong number of columns selected by subquery against composite primary key	Jacob Walls	Jacob Walls	"Discovered during [https://github.com/django/django/pull/19459#discussion_r2087862732 review] of #36210 that the guard for the appropriate number of columns selected in a subquery is not aware that `""pk""` might represent N columns, so the `ValueError` that should be raised is evaded, failing instead at the db layer.

We're just changing one type of exception to another--so this isn't terribly serious--but in the interest of standardizing what kinds of exceptions are raised during usage of the composite pk feature, starting out at release blocker?

{{{#!diff
diff --git a/tests/composite_pk/test_filter.py b/tests/composite_pk/test_filter.py
index 16c4c2a91a..f629f85ca6 100644
--- a/tests/composite_pk/test_filter.py
+++ b/tests/composite_pk/test_filter.py
@@ -207,6 +207,10 @@ class CompositePKFilterTests(TestCase):
             [self.comment_1],
         )
 
+    def test_invalid_filter_by_pk_in_columns_besides_pk(self):
+        with self.assertRaisesMessage(ValueError, ""must have 2 selected fields""):
+            User.objects.filter(pk__in=User.objects.values(""pk"", ""email"")).count()
+
     def test_filter_by_pk_in_none(self):
         with self.assertNumQueries(0):
             self.assertSequenceEqual(
}}}

----
Postgres failure looks like:
{{{#!py
  File ""/Users/.../django/django/db/backends/sqlite3/base.py"", line 360, in execute
    return super().execute(query, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
django.db.utils.OperationalError: sub-select returns 3 columns - expected 2

}}}"	Bug	closed	Database layer (models, ORM)	5.2	Release blocker	fixed	pk		Ready for checkin	1	0	0	0	0	0