alessandro-nori opened a new pull request, #2104:
URL: https://github.com/apache/iceberg-go/pull/2104

   ## Changes
   - represent validated REST identifiers with explicit encoded namespace, raw 
name, and encoded name fields
   - use raw object names for JSON payloads and encoded values for endpoint 
paths
   - name table, view, and function path builders according to the identifiers 
they validate
   - encode literal `+` in opaque scan plan IDs while retaining the existing 
protection for `.` and `..` plan IDs
   
   ## Motivation
   This follows #2074. Keeping raw and encoded object names as separate strings 
at each call site makes it easy to accidentally place an encoded path value in 
a JSON request body. A typed internal representation makes that distinction 
explicit and applies it consistently across table, view, function, metrics, 
credentials, and scan-planning endpoints.
   
   The review of #2074 also identified that scan plan IDs used a separate path 
encoder that left literal `+` unchanged. Reusing the identifier segment encoder 
aligns that behavior while preserving the scan-specific handling of pure dot 
segments.
   
   ## Known follow-ups
   This PR intentionally does not otherwise change identifier encoding 
behavior. In particular:
   - Go's `url.PathEscape` leaves some RFC 3986 reserved characters such as 
`&`, `:`, `@`, `=`, and `$` literal, unlike Iceberg Java's stricter 
path-segment encoder.
   - pure `.` and `..` identifier segments can still be normalized by 
`url.URL.JoinPath`; scan plan IDs already protect against this separately.
   
   ## Testing
   - `make lint`
   - `go test ./catalog/...`
   - `go test -race ./catalog/rest`
   


-- 
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