uros-b commented on code in PR #18057:
URL: https://github.com/apache/iceberg/pull/18057#discussion_r3988000960


##########
format/udf-spec.md:
##########
@@ -107,7 +107,11 @@ Notes:
 Types are based on the [Iceberg 
Type](https://iceberg.apache.org/spec/#schemas-and-data-types).
 
 Primitive and semi-structured type strings are encoded based on [Iceberg Type 
JSON Representation][iceberg-type-json]
-(e.g., `int`, `string`, `timestamp`, `decimal(9,2)`, `variant`). Type strings 
must contain no spaces or quote characters.
+(e.g., `int`, `string`, `timestamp`, `decimal(9, 2)`, `variant`). Type strings 
must contain no quote characters.
+
+Type strings are used exactly as Iceberg serializes them. Parameterized types 
may contain spaces, either separating
+parameters (`decimal(9, 2)`, `geography(OGC:CRS84, spherical)`) or within a 
parameter value (`geometry(srid: 3857)`).
+Readers must not add or remove spaces in a type string.

Review Comment:
   This is phrased a bit too broadly. The intent is that whitespace inside a 
type string is semantically significant and must not be stripped or normalized 
during comparison (geometry(srid: 3857) ≠ geometry(srid:3857), CRS comparison 
is case-insensitive but not space-insensitive per GeometryType.equals()). 
However, the rule as written could be read as prohibiting write-side 
canonicalization, e.g. the normalization path in the upcoming #15994 
(Types.fromTypeName(s).toString()) deliberately adds a space when given 
old-form decimal(9,2) → decimal(9, 2). Please consider rephrasing to scope it 
to comparison semantics: "Implementations must compare type strings exactly as 
written; whitespace inside a type string is semantically significant and must 
not be stripped or normalized for comparison purposes."



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to