Skip to content

GuidSet reads Guid.Parse's grammar, not uuid_in's: accepts (…), refuses hyphen groups #129

Closed

Description

@CaffeinatedCoder

GuidSet reads Guid.Parse's grammar instead of uuid_in's, in both directions. Measured on main (3ecfa10) against PostgreSQL 17.10:

GuidSet.Parse("{(6f9619ff-8b86-d011-b42d-00c04fc964ff)}", null);   // parses: Guid's "P" format
GuidSet.Parse("{6f96-19ff-8b86-d011-b42d-00c0-4fc9-64ff}", null);  // FormatException
SELECT '{(6f9619ff-8b86-d011-b42d-00c04fc964ff)}'::uuid[];  -- invalid input syntax for type uuid
SELECT '{6f96-19ff-8b86-d011-b42d-00c0-4fc9-64ff}'::uuid[]; -- {6f9619ff-8b86-d011-b42d-00c04fc964ff}

GuidSet and GuidSet<T>. Found by LiteralCorpusProbeTests (#123), families parentheses and hyphen groups. The same cause as #78 (whitespace Guid.Parse trims and uuid_in rejects), which this sweep registers separately; one fix can close both.

Authority. docs/value-sets.md#parse-and-print-literals: "The grammar is PostgreSQL's array_in", with each element read by the element type's input function, and docs/serialization.md: the text is "the same text the server itself reads".

Cause. GuidSet.ParseValue is Guid.Parse(s), which takes the N, D, B, P and X formats and trims whitespace. uuid_in takes 32 hex digits, optionally in braces, with a hyphen after any group of four.

Fix (10.0.0). Parse uuid_in's grammar: refuse (…) (and X), accept hyphen groups. Refusing input that parses today is breaking, so it goes in the major.

Activity

  1. added this to the 10.0.0 milestone on Oct 17, 2026
  2. added
    bugSomething isn't working
    breakingChanges an answer or a signature — needs a major
    found-by/oracleFound by the generated-oracle machinery (claims × API surfaces)
    area/value-setsValue set families and wrapper arities
    area/literalsParse, TryParse and formatting
    package/coreAffects CodoMetis.ValueRanges
    severity/lowCosmetic, message or documentation-level difference
    on Oct 17, 2026
  3. CaffeinatedCoder commented on Oct 18, 2026

    @CaffeinatedCoder
    OwnerAuthor

    The clone-divergence sweep (#140) names a third parse site for the fix: the GuidSet<> wrapper-family bridge in SetTypeRegistry reads with Guid.Parse(text, Invariant) directly rather than through GuidSet.ParseValue. Today that is the same grammar, so it is waived in test/oracles/clone-waivers.json with a pointer here; a fix to GuidSet.ParseValue alone would leave a bound GuidSet<T> element reading Guid.Parse's grammar. Route the bridge through GuidSet.ParseValue (as the integer bridges already do) in the same change, then the waiver goes stale and is removed.

  4. CaffeinatedCoder commented on Oct 18, 2026

    @CaffeinatedCoder
    OwnerAuthor

    Fixed in #162 (with #78): UuidLiteral is the one uuid_in grammar — 32 hex digits, a hyphen allowed after any group of four, optional braces, nothing else — read by GuidSet.ParseValue, by GuidSet<T>.ParseValue (which now hands the element the D form, as the numeric arities hand theirs the primitive's text) and by the EF bridge for GuidSet<>, which goes through GuidSet.ParseValue so the clone waiver named here is gone. {(…)} throws, {6f96-19ff-…} parses. Proven by reverting the fix.

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

    area/literalsParse, TryParse and formattingarea/value-setsValue set families and wrapper aritiesbreakingChanges an answer or a signature — needs a majorbugSomething isn't workingfound-by/oracleFound by the generated-oracle machinery (claims × API surfaces)package/coreAffects CodoMetis.ValueRangespackage/efcoreAffects CodoMetis.ValueRanges.EFCore.PostgreSQLseverity/lowCosmetic, message or documentation-level difference

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions