Repository navigation
GuidSet accepts whitespace inside an element that PostgreSQL's uuid_in rejects #78
Description
GuidSet accepts whitespace inside an element that PostgreSQL's uuid_in rejects.
GuidSet.Parse("{\" 6f9619ff-8b86-d011-b42d-00cf4fc964ff\"}", null); // parses
GuidSet.Parse("{\\ 6f9619ff-8b86-d011-b42d-00cf4fc964ff}", null); // parses
GuidSet.Parse("{ 6f9619ff-8b86-d011-b42d-00cf4fc964ff}", null); // parses, even bareSELECT '{" 6f9619ff-8b86-d011-b42d-00cf4fc964ff"}'::uuid[]; -- invalid input syntax for type uuid
SELECT '{ 6f9619ff-8b86-d011-b42d-00cf4fc964ff}'::uuid[]; -- fine: array_in drops bare ASCII whitespaceThis was measured on PostgreSQL 17 while fixing #70; the table is in the comment there. GuidSet.ParseValue calls Guid.Parse, which trims all Unicode whitespace. uuid_in trims none. Bare ASCII whitespace is fine, because array_in drops it before uuid_in sees the element. A no-break space isn't ASCII, so array_in keeps it and uuid_in rejects it.
The library doesn't return a wrong value here. It parses text that PostgreSQL rejects, so {" …"} parses in memory and then fails when it reaches the database as a literal. Fixing it means rejecting input that parses today, so it belongs in 10.0.0, not a minor. It should also cover GuidSet<T>, which parses as Guid first.
Activity
CaffeinatedCoder commentedon Oct 17, 2026
Oracle check (main at 3ecfa10): Would be caught today (retroactive; it was found while fixing #70, not by an oracle) by
SetElementWhiteSpaceContractTestsandLiteralGrammarParityTests. The failing rows:SetElementWhiteSpaceContractTests(rowsGuidSet: accepts whitespace uuid_in rejectsandGuidSet<TenantId>: …, through Parse, TryParse, TypeConverter and JSON) andLiteralGrammarParityTests(ElementWhitespace_ReadsAsPostgresReadsIt, rowuuid[] GuidSet).Verified by a run on 3ecfa10, where the defect is unfixed. 162 lines report
SKIPPED [known candidate: Guid.Parse trims whitespace uuid_in rejects, #78]fromcandidates.json, and they will fail ascandidate fixedonce the fix lands.CaffeinatedCoder commentedon Oct 17, 2026
Would be caught today by
LiteralCorpusProbeTests(#135), alongsideSetElementWhiteSpaceContractTestsandLiteralGrammarParityTests, which found it. Row:GuidSet whitespace {00000000-0000-0000-0000-000000000001 }(and{" …"},{\ …}): library reads the uuid, PostgreSQL refuses. The same holds forGuidSet<TenantId>. Verified against postgres:17 on main + #135, where the defect is still present. The proof is thecandidates.jsonrowsGuidSet whitespace/GuidSet<TenantId> whitespace→ #78. The relatedGuid.Parsegrammar cells (the(…)form accepted, hyphen groups refused) are #129.test: literal corpus × entry point against PostgreSQL (route B, step 3)
CaffeinatedCoder commentedon Oct 18, 2026
Fixed in #162 (with #129, one change):
GuidSet.ParseValuereadsuuid_in's grammar through the newUuidLiteral, so whitespace inside a quoted or escaped element is refused (FormatException) throughParse,TryParse, theTypeConverterand JSON, forGuidSetandGuidSet<T>alike; bare ASCII whitespace around an element is still dropped by the array grammar, asarray_indrops it.SetElementWhiteSpaceContractTests,LiteralGrammarParityTestsandLiteralCorpusProbeTestshold their Guid rows without candidates. Proven by reverting the fix.