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
36048	CompositePrimaryKey lookup guards raise NotSupportedError instead of a more appropriate exception	Jacob Walls	Jacob Walls	"Django mostly(*) raises `NotSupportedError` as documented in [https://peps.python.org/pep-0249/#notsupportederror PEP 249], to signify that a database feature is missing. Instead, some of the `CompositePrimaryKey` sanity checks raise regardless of db feature flags. Given that, I'm suggesting that `ValueError` etc. would be more appropriate in these two locations:

- [https://github.com/django/django/blob/8d9901c961bf9d5cfa6bddddbbcebfbf487a5125/django/db/models/fields/related_lookups.py#L120 RelatedLookupMixin.as_sql]
- [https://github.com/django/django/blob/8d9901c961bf9d5cfa6bddddbbcebfbf487a5125/django/db/models/aggregates.py#L185 Count.resolve_expression]

Our [https://github.com/django/django/blob/8d9901c961bf9d5cfa6bddddbbcebfbf487a5125/django/db/backends/base/operations.py#L663 guidance] says ""specific backends"":
> This is used on specific backends to rule out known expressions that have problematic or nonexistent implementations. If the expression has a known problem, the backend should raise NotSupportedError.

Essentially the inverse of #28665. Marking as a release blocker for now to ensure we consider this before finalizing the feature.

----
*: The handful of places we're raising `NotSupportedError` regardless of db feature flags include:
- Query.check_filterable
- QuerySet._not_support_combined_queries
- QuerySet.get
- Field.slice_expression
- ResolvedOuterRef.resolve_expression

I'm not suggesting to do anything about those at the moment."	Bug	closed	Database layer (models, ORM)	dev	Release blocker	fixed		Jacob Walls Csirmaz Bendegúz Simon Charette	Ready for checkin	1	0	0	0	0	0