Skip to content

Document that range mappings resolve by store type name #56

Closed

Description

@CaffeinatedCoder

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).

Activity

  1. added this to the 9.1.0 milestone on Oct 17, 2026
  2. added
    documentationImprovements or additions to documentation
    found-by/oracleFound by the generated-oracle machinery (claims × API surfaces)
    package/efcoreAffects CodoMetis.ValueRanges.EFCore.PostgreSQL
    on Oct 17, 2026
  3. removed this from the 9.1.0 milestone on Oct 17, 2026
  4. CaffeinatedCoder commented on Oct 17, 2026

    @CaffeinatedCoder
    OwnerAuthor

    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.

  5. added this to the 10.3.0 milestone on Oct 25, 2026
  6. CaffeinatedCoder commented on Oct 25, 2026

    @CaffeinatedCoder
    OwnerAuthor

    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.

  7. CaffeinatedCoder commented on Oct 25, 2026

    @CaffeinatedCoder
    OwnerAuthor

    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.

  8. added a commit that references this issue on Oct 25, 2026
  9. CaffeinatedCoder commented on Oct 25, 2026

    @CaffeinatedCoder
    OwnerAuthor

    Merged on both lines; #460 was the release/10.x PR. Closed by hand, since Closes acts only on main.

  10. added a commit that references this issue on Oct 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationfound-by/oracleFound by the generated-oracle machinery (claims × API surfaces)package/efcoreAffects CodoMetis.ValueRanges.EFCore.PostgreSQLpackage/efcore-nodatimeAffects CodoMetis.ValueRanges.EFCore.PostgreSQL.NodaTime

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions