huaxingao commented on code in PR #18057:
URL: https://github.com/apache/iceberg/pull/18057#discussion_r4029509224
##########
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
Review Comment:
Good questions.
On conflicts: `foo` and `bar` are different functions, and definition-ids
only have to be unique within one function, so those two can't clash. The case
that matters is one function ending up with both `foo(geometry(srid: 3857))`
and `foo(geometry(srid:3857))`. That would only happen by accident, though. No
one would write both on purpose.
On encoding: `definition-id` only lives inside JSON. It's a field on
`FunctionDefinition`, not a path or query parameter, so a space in it doesn't
need encoding.
Agreed a CRS with a space is unusual. The main reason to keep spaces isn't
geometry, it's that `DecimalType.toString()` gives you `decimal(9, 2)` with the
space. So anything that builds the id from Iceberg's own serialization gets
that space, and saying "no spaces" means everyone has to strip it themselves.
Geometry is just why we can't strip spaces everywhere.
--
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]
