[CaffeinatedCoder]

Closes #507

Stacked on #509 (both edit the same migration list and changelog section). Review only the last three commits.

Problem

PostgreSQL takes an operator's collation from both sides. #483 checks only the string set's own collation: the property when the model is built, and EF.Functions.Collate over the set. Suppose the set column has no collation, which is the fix #483's error message suggests, and Owner has a case-insensitive one. With Members holding {A,b} and Owner holding "a":

• Members.Contains(g.Owner) matched the row (@> compared under the value's collation). Memory gives false.
• ExecuteUpdate(… Members.Remove(g.Owner)) stored {b}. Memory keeps {A,b}.
• Members.Contains(EF.Functions.Collate("a", "case_insensitive")) matched too.

Change

• ValueSetSqlGuard walker (Compared, Collation, ColumnCollation): at @>, <@, &&, array_remove, == and the text set placeholders that involve a string set, it derives the operator's collation the way PostgreSQL does:

  • an explicit COLLATE wins;
  • otherwise the column's, or a subquery or set-operation column's projection;
  • or what a string-typed function, operator or array takes from its string-typed inputs;
  • a CASE contributes its results, not its tests.

  If that collation may not compare bytes, the query throws and names it. EF.Functions.Collate over the set itself keeps Text value set operators follow a nondeterministic column collation: on a case-insensitive column, Contains("a") is true for {A} and Remove("a") deletes A #483's message.

• StringSetCollationConvention: the read-optimized model a query runs on keeps no collation, so property.GetCollation() throws there. The convention that already visits every property now names each other non-byte collation in an annotation (CodoMetis:ValueRanges:Collation), and the guard reads it. A compiled model carries the annotation (tested).

• Remedy: EF.Functions.Collate(g.Owner, "C"). Measured on PostgreSQL 16 over an en_US database: an explicit "C" on the value turns an indexed @> into a sequential scan unless the set column is "C" too. The migration section says so.

• Docs: the value-set entry in efcore.md, the v10.x migration list and Check string set columns with a collation, ### Breaking lines in 11.0.0-preview.1 (root and EF Core), and claim E89.

• Oracles: StringSetCollationTests is registered as an exception oracle, with two seeds.

It changes answers, so it's labelled silent. On 10.x: #512.

Tests

• StringSetCollationIntegrationTests (live): Contains, !Contains, Remove, Add().Count, ToLower(), EF.Functions.Collate, a subquery's column and ExecuteUpdate with Remove each throw and name the collation, and the row stays unchanged. A "C" column, Collate(Owner, "C"), and a CASE that only tests Owner run and answer as memory does. The rejection also holds on a compiled model, generated as dotnet ef dbcontext optimize does. CompiledModelJsonTests.CompileModel now takes any context.
• StringSetCollationTests: adds a derived table's column, a set operation's column, a concatenation and a CASE result.
• Proved by reverting: without the walker's throw, all three new tests fail, because each query runs instead of throwing. oracles.cs seeds string-set-collation catches both seeds: the throw removed, and the convention leaving the column unnamed.
• Full suite green on PostgreSQL 16, and the collation, Union and compiled-model classes on 18.

🤖 Generated with Claude Code