Repository navigation
fix: reject a string set compared with a value under a collation that may not compare bytes (#512, port of #507) - #516
Merged
CaffeinatedCoder merged 5 commits intoOct 26, 2026
Conversation
… may not compare bytes (#507) PostgreSQL derives an operator's collation from both sides, and #483 only checks the set's: a value from a case-insensitive column, or collated by EF.Functions.Collate, made @>, && and array_remove compare case-insensitively with the set column uncollated, as the remedy leaves it. Members.Contains(g.Owner) matched {A,b} for "a", and ExecuteUpdate with Members.Remove(g.Owner) stored {b}, where memory keeps {A,b}. The guard's walker now derives the collation of a string set operator's operands as PostgreSQL does (an explicit COLLATE wins; a column's; a subquery or set-operation column's projection; what a string-typed function, operator or array takes from its string inputs; a CASE's results, not its tests) at @>, <@, &&, array_remove, == and the text set placeholders, and throws for one that may not compare bytes, naming it. EF.Functions.Collate(value, "C") compares as memory does. The read-optimized model a query runs on keeps no collation, so the convention that rejects a collated string set column names every other non-byte collation on its property (CodoMetis:ValueRanges:Collation), which a compiled model carries. StringSetCollationIntegrationTests rejects Contains, !Contains, Remove, Add().Count, ToLower(), EF.Functions.Collate, a subquery's column and ExecuteUpdate with Remove on a live server and leaves the row unchanged, runs "C" and a CASE that only tests the column as memory answers, and holds the rejection on a compiled model; StringSetCollationTests adds a derived table's and a set operation's column, a concatenation and a CASE result. Without the walker check every rejection runs and answers. Found-By: CA Defect-Class: SQL Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit cb48b63)
…e migration and changelog (#512) The value set entry in efcore.md gains the value's side and the EF.Functions.Collate(value, "C") remedy; Check string set columns with a collation, under Changed answers in 10.4.0, gains it with its before and after table and the GIN index cost of an explicit "C"; the Changed answers rows of 10.4.0 in the root and EF Core changelogs link #512; claim E89. (cherry picked from commit 6e4be22, with the 10.x changelog and migration layout) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CaffeinatedCoder
added
bug
Base automatically changed from
fix/511-yearmonth-upper-bound-10.x
to
release/10.x
October 26, 2026 17:29
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #512
Port of #513 (#507) to
release/10.x, stacked on #515 (both edit Changed answers in 10.4.0 and the changelogs). Review only the last three commits. The fix and seed commits are cherry-picked with-xand applied without conflicts. The docs commit is re-made for 10.x's layout.Problem
PostgreSQL takes an operator's collation from both sides, and #496 checks only the string set's own. Take a case-insensitive
OwnerandMembersholding{A,b}:Members.Contains(g.Owner)matched for"a".ExecuteUpdatewithRemove(g.Owner)stored{b}.#496's 10.4.0 row says that class is fixed.
Change
As #513:
EF.Functions.Collate(value, "C")is the fix you can write.CompiledModelJsonTests.CompileModeltakes any context.10.x specifics:
### Changed answersrows in[10.4.0](root and EF Core), linking 10.x: reject a string set compared with a value under a collation that may not compare bytes (port of #507) #512 and#changed-answers-in-1040. They are shorter thanmain's, to stay inside the changelog's word limit with the issue link.## Changed answers in 10.4.0, gains the value side.main.Tests
On
release/10.x, EF Core 10.0.0 floor:oracles.cs seeds string-set-collation: both seeds caught byStringSetCollationTests.-p:EfFloat=10.0.13 -p:NpgsqlEfFloat=10.0.3):StringSetCollationIntegrationTestswithCompiledModelJsonTests4/4, andStringSetCollationTests10/10.StringSetCollationIntegrationTests, 3/3.🤖 Generated with Claude Code