[CaffeinatedCoder]

Closes #354

The 10.x port of #349 for 10.2.0 (#358): git cherry-pick -x of #352's commit (2c44472) and #353's fix commit (89a7a38), both merged into main. Against release/10.x the closing keyword closes nothing, so #354 is closed by hand after the merge.

Problem

10.1.0 declares lower() and upper() with argumentsPropagateNullability: [true], so EF Core takes a bound as NULL only when its column is. PostgreSQL also returns NULL for the empty range and for an unbounded side, as the in-memory LowerBound() and UpperBound() return null. Over a required column:

• LowerBound() == null became WHERE FALSE;
• != null and HasValue filtered nothing;
• ?? fallback lost its COALESCE, so open-ended rows fell out of a filter and a projection threw.

On a nullable column, the bound was tested with the column's own IS NULL. This affects every range type and RangeSet.

Change

• The two commits, as on main: the flag becomes [false] in BoundFunction. ExecutedQueryTests gets the bound sweep, over the range and RangeSet columns of all 13 families, and the nullable-column sweep for A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350. QueryTranslationTests gets the two SQL pins. Claim E70 is added, and the nine LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? max loses its COALESCE, because lower() and upper() are declared NULL only for a NULL argument #349 candidates are added and then removed, leaving A null range answers some extensions in memory and throws on others, and the answers it gives disagree with PostgreSQL on a NULL column #350's twelve.
• Conflicts resolved for 10.x:
  • claims.json: only E70 is taken. main's E64–E69 are 11-line claims (Npgsql 11's temporal keys) and stay out.
  • Changelogs: main's ### Breaking line under [11.0.0-preview.1] becomes a ### Changed answers row under [10.2.0], in the root, EF Core and EF Core NodaTime changelogs. It links 10.x: LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? loses its COALESCE (port of #349) #354 and docs/migration.md#changed-answers-in-1020. The root section opens with a line pointing there.
  • docs/migration.md: main's ## Migration from v10.x becomes ## Changed answers in 10.2.0, with the same subsection, ### Check bound comparisons with null in queries, where "Before 11.0.0" reads "Before 10.2.0". When 10.2.0 is carried to main (Release 10.2.0: date the changelogs, tag v10.2.0, close the 10.x-only issues, carry the sections to main #365), that subsection meets its twin; Release 10.2.0: date the changelogs, tag v10.2.0, close the 10.x-only issues, carry the sections to main #365 says how to reconcile them.
• docs/efcore.md: the sentence that claim E70 quotes.

Tests

Local, SDK 10.0.402, Docker:

• Full suite, EF Core 10.0.0 floor, postgres:16-alpine: all eight projects pass (core 1397, NodaTime 238, EF 305, EF NodaTime 91, ASP.NET Core 92, conventions 406, integration 282, infinity-disabled 4).
• ExecutedQueryTests on postgres:18-alpine: 15/15.
• EF Core 10.0.13 with Npgsql 10.0.3 (-p:EfFloat=10.0.13 -p:NpgsqlEfFloat=10.0.3, versions confirmed in deps.json): translation tests 305/305, ExecutedQueryTests 15/15.
• Fix reverted on this branch ([true]): the bound sweep fails on 234 rows (117 range, 117 RangeSet), none a known candidate, and both translation pins fail. Restored afterwards.
• pr-hygiene.sh on a simulated event with silent: "Labels and issue link are in order", so the [10.2.0] ### Changed answers row links 10.x: LowerBound() and UpperBound() in a query: == null becomes WHERE FALSE and ?? loses its COALESCE (port of #349) #354.

🤖 Generated with Claude Code