You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Document that range mappings resolve by store type name #56
With the plugin active, the range mappings resolve by store type name: int4range resolves to Int32Range. Value sets deliberately don't do this, because text[] belongs to the provider's own string[] mapping.
It's harmless for scaffolding, but no document says so. A consumer who writes HasColumnType("int4range") on an NpgsqlRange<int> property, or reads the mapping by name, should know which CLR type answers.
Add it to docs/efcore.md, and decide whether the asymmetry with value sets is intended (it probably is). Found during the probing round (#52).
Moved off 9.1.0 into the backlog (#83), with no milestone.
release/9.x has been cut, and 9.1.0 ships with the work that's already finished. Nothing has started on this issue, and it shouldn't hold up the tag. Docs, tests and internal work aren't tied to a version, so this doesn't need a milestone until someone picks it up.
When someone picks it up, it goes under the epic of the release it will ship in and takes that milestone. A 9.x minor would need the change cherry-picked onto release/9.x.
Scheduled for 10.3.0 (#408), 2026-10-25. Docs only, so it adds no release risk. It lands on main first and is cherry-picked into release/10.x, like the other docs items, and moves to the next minor if it isn't done in time. Re-checked 2026-10-25: docs/efcore.md doesn't mention it on either line.
Documented in #457 (main) and #460 (release/10.x), held by claim E77 and two new test classes. Measuring it turned up one case the issue didn't mention: with UseValueRangesNodaTime, Npgsql's own NodaTime plugin resolves daterange, tsrange and tstzrange by name before ours (DateInterval, NpgsqlRange<LocalDateTime>, Interval), while the multiranges stay ours. Properties are mapped by CLR type, so only a lookup by name sees this. The doc says so. The value set asymmetry is intended: text[] also belongs to string[]. Added package/efcore-nodatime. Close by hand once both merge.
Activity
CaffeinatedCoder commentedon Oct 17, 2026
Moved off 9.1.0 into the backlog (#83), with no milestone.
release/9.xhas been cut, and 9.1.0 ships with the work that's already finished. Nothing has started on this issue, and it shouldn't hold up the tag. Docs, tests and internal work aren't tied to a version, so this doesn't need a milestone until someone picks it up.When someone picks it up, it goes under the epic of the release it will ship in and takes that milestone. A 9.x minor would need the change cherry-picked onto
release/9.x.CaffeinatedCoder commentedon Oct 25, 2026
Scheduled for 10.3.0 (#408), 2026-10-25. Docs only, so it adds no release risk. It lands on
mainfirst and is cherry-picked intorelease/10.x, like the other docs items, and moves to the next minor if it isn't done in time. Re-checked 2026-10-25:docs/efcore.mddoesn't mention it on either line.CaffeinatedCoder commentedon Oct 25, 2026
Documented in #457 (
main) and #460 (release/10.x), held by claim E77 and two new test classes. Measuring it turned up one case the issue didn't mention: withUseValueRangesNodaTime, Npgsql's own NodaTime plugin resolvesdaterange,tsrangeandtstzrangeby name before ours (DateInterval,NpgsqlRange<LocalDateTime>,Interval), while the multiranges stay ours. Properties are mapped by CLR type, so only a lookup by name sees this. The doc says so. The value set asymmetry is intended:text[]also belongs tostring[]. Addedpackage/efcore-nodatime. Close by hand once both merge.Merge pull request #460 from CaffeinatedCoder/docs/56-store-type-name…
CaffeinatedCoder commentedon Oct 25, 2026
Merged on both lines; #460 was the
release/10.xPR. Closed by hand, sinceClosesacts only onmain.Merge pull request #457 from CaffeinatedCoder/docs/56-store-type-name…