szehon-ho commented on code in PR #18057:
URL: https://github.com/apache/iceberg/pull/18057#discussion_r4021196992
##########
format/udf-spec.md:
##########
@@ -118,19 +122,26 @@ following fields required. Any other fields must be
ignored.
e.g., `{ "type": "struct", "fields": [ { "name": "id", "type": "int" }, {
"name": "name", "type": "string" } ] }`
#### Definition ID
-The `definition-id` is a canonical string derived from the parameter types,
formatted as a comma-separated list with no
-spaces. Each type uses the following string representation:
+The `definition-id` is a canonical string derived from the parameter types,
formatted as a comma-separated list. The
+separators that this format adds must not be followed by a space. Each type
uses the following string representation:
* Primitives and semi-structured: the type name (e.g., `int`, `variant`)
* List: `list<element-type>` (e.g., `list<int>`)
* Map: `map<key-type,value-type>` (e.g., `map<string,int>`)
* Struct: `struct<name1:type1,name2:type2,...>` with field names and types
(e.g., `struct<id:int,name:string>`)
+In a struct field name, `\`, `:`, `,`, `<`, and `>` must each be escaped with
a preceding `\`. Without escaping, a
+field name that contains a separator would produce the same string as a
different set of fields.
+
Examples of complete definition-id signatures:
* `int` – single int parameter
* `int,string` – two parameters: int and string
* `int,list<int>,struct<id:int,name:string>` – three parameters: an int, a
list and a struct
+* `decimal(9, 2),geometry(srid: 3857)` – two parameterized parameters, each
keeping its own spaces
+* `geometry(epsg:4326)` – a geometry parameter; CRS values are lowercased, so
`geometry(EPSG:4326)` yields this id
Review Comment:
i believe it'd be better to preserve the crs case, can we do that? i dont
think we need to specifically dictate it and most catalog will be
case-insensitive in any event, but it align with the table spec's serialization
of it.
##########
format/udf-spec.md:
##########
@@ -118,19 +122,26 @@ following fields required. Any other fields must be
ignored.
e.g., `{ "type": "struct", "fields": [ { "name": "id", "type": "int" }, {
"name": "name", "type": "string" } ] }`
#### Definition ID
-The `definition-id` is a canonical string derived from the parameter types,
formatted as a comma-separated list with no
-spaces. Each type uses the following string representation:
+The `definition-id` is a canonical string derived from the parameter types,
formatted as a comma-separated list. The
+separators that this format adds must not be followed by a space. Each type
uses the following string representation:
* Primitives and semi-structured: the type name (e.g., `int`, `variant`)
* List: `list<element-type>` (e.g., `list<int>`)
* Map: `map<key-type,value-type>` (e.g., `map<string,int>`)
* Struct: `struct<name1:type1,name2:type2,...>` with field names and types
(e.g., `struct<id:int,name:string>`)
+In a struct field name, `\`, `:`, `,`, `<`, and `>` must each be escaped with
a preceding `\`. Without escaping, a
+field name that contains a separator would produce the same string as a
different set of fields.
+
Examples of complete definition-id signatures:
* `int` – single int parameter
* `int,string` – two parameters: int and string
* `int,list<int>,struct<id:int,name:string>` – three parameters: an int, a
list and a struct
+* `decimal(9, 2),geometry(srid: 3857)` – two parameterized parameters, each
keeping its own spaces
+* `geometry(epsg:4326)` – a geometry parameter; CRS values are lowercased, so
`geometry(EPSG:4326)` yields this id
Review Comment:
i believe it'd be better to preserve the crs case, can we do that for the
example? i dont think we need to specifically dictate it and most catalog will
be case-insensitive in any event, but it align with the table spec's
serialization of it.
--
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]
