[CaffeinatedCoder]

Closes #56

Cherry-pick (-x) of #457 into release/10.x, for 10.3.0. Closes doesn't act on a release branch, so #56 is closed by hand once both PRs merge.

Problem

With the plugin active, a range or multirange store type name resolves to this package's types (int4range → Int32Range), and value sets deliberately don't resolve by name. No document said so, so a reader who writes HasColumnType("int4range") on an NpgsqlRange<int> property, or looks a mapping up by name, couldn't know which CLR type they get.

While measuring this I found one more case: with UseValueRangesNodaTime, Npgsql's own NodaTime plugin resolves daterange, tsrange and tstzrange before ours (DateInterval, NpgsqlRange<LocalDateTime>, Interval). The multiranges still resolve to the core RangeSet types. A NodaTime range property is still mapped by its CLR type, so this only matters for a lookup by name.

Change

docs/efcore.md#map-ranges-to-postgresql-columns gets three Good-to-know bullets:

• A property's type picks its mapping, before any column type. An NpgsqlRange<int> property keeps Npgsql's mapping. An Int32Range property with int8range fails at model building (InvalidOperationException).
• A range or multirange column type on its own maps to these types, with the NodaTime exception above.
• An array column type on its own stays Npgsql's. text[] is also the column type of every string[] property, so a value set maps only from a property typed as one. The asymmetry is intended, as the issue expected.

Claim E77 quotes the second bullet and names both new test classes.

Tests

• StoreTypeNameResolutionTests (EF Core, no database): all 18 range and multirange names; 12 array names, none resolving to a value set; the NpgsqlRange<int> property; the mismatched column type.
• NodaStoreTypeNameResolutionTests: the three names Npgsql's NodaTime plugin takes first, five that stay ours, and the NodaTime range properties mapped by CLR type.
• Seeded both ways (on main, docs: say what a store type name maps to on its own (#56) #457): a range plugin that ignores store type names fails all 18 name rows, and a set plugin that takes text[] fails the array row.
• On release/10.x with SDK 10.0.402, both classes (32 and 9 tests) and the conventions tests (420) pass.

🤖 Generated with Claude Code