Repository navigation
docs: say what a store type name maps to on its own (#56) - #457
Merged
Merged
Conversation
docs/efcore.md (Map ranges to PostgreSQL columns) gains three Good-to-know bullets:
- a property's CLR type picks its mapping before any column type: an
NpgsqlRange<int> with HasColumnType("int4range") keeps Npgsql's, and an
Int32Range with HasColumnType("int8range") fails at model building;
- a range or multirange name on its own maps to this package's types, except that
with UseValueRangesNodaTime Npgsql's NodaTime plugin takes daterange, tsrange and
tstzrange first;
- an array name stays Npgsql's, because text[] also belongs to string[]; a value set
maps only from a property typed as one. The asymmetry is intended.
StoreTypeNameResolutionTests and NodaStoreTypeNameResolutionTests hold all of it
(claim E77). Seeded both ways: a name-blind range plugin fails the 18 name rows, and
a set plugin that takes text[] fails the array row.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 25, 2026
Closed
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 #56
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 writesHasColumnType("int4range")on anNpgsqlRange<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 resolvesdaterange,tsrangeandtstzrangebefore ours (DateInterval,NpgsqlRange<LocalDateTime>,Interval). The multiranges still resolve to the coreRangeSettypes. 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-columnsgets three Good-to-know bullets:NpgsqlRange<int>property keeps Npgsql's mapping. AnInt32Rangeproperty withint8rangefails at model building (InvalidOperationException).text[]is also the column type of everystring[]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; theNpgsqlRange<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.text[]fails the array row.🤖 Generated with Claude Code