CompositePrimaryKey lookup guards raise NotSupportedError instead of a more appropriate exception

[Jacob Walls]

Django mostly(*) raises NotSupportedError as documented in ​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:

• ​RelatedLookupMixin.as_sql
• ​Count.resolve_expression

Our ​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.

[Sarah Boyce]

I think I agree

[Jacob Walls]

​PR

[Sarah Boyce <42296566+sarahboyce@…>]

In 46b3e7dd:

Fixed #36048 -- Preferred ValueError to NotSupportedError for composite pk sanity checks.

These checks are not backend-dependent.