rraulinio opened a new issue, #1433:
URL: https://github.com/apache/iceberg-go/issues/1433

   ### Feature Request / Improvement
   
   ## Summary
   
   This is a follow-up to #1360.
   
   iceberg-go now has the foundation for SQL UDF catalog support:
   
   - #1418 adds the spec-validated `udf` metadata model and metadata builder.
   - #1432 adds the REST catalog read side for listing and loading functions.
   
   The current Iceberg REST OpenAPI defines only the read-side function 
operations:
   
   - `GET /v1/{prefix}/namespaces/{namespace}/functions`
   - `GET /v1/{prefix}/namespaces/{namespace}/functions/{function}`
   
   The OpenAPI does not currently define standardized function write routes or 
request/response contracts for operations such as create, replace/update, drop, 
or commit. The REST spec change that introduced list/load support was 
intentionally scoped as read-only Stage 1 and deferred function CRUD to a 
follow-up proposal: https://github.com/apache/iceberg/pull/15180.
   
   The `udf` metadata builder can construct valid immutable metadata, but a 
REST client still needs a standardized catalog protocol for publishing that 
metadata and atomically changing the catalog's current metadata pointer. Until 
that protocol exists, iceberg-go should not introduce implementation-specific 
REST routes or wire models that may diverge from the eventual Iceberg contract.
   
   ## Desired outcome
   
   Once the Apache Iceberg REST catalog specification defines function write 
operations, add the corresponding generic client support to iceberg-go using 
the standardized contracts.
   
   The implementation should, as applicable to the final specification:
   
   - expose write operations through an optional catalog capability interface, 
consistent with existing iceberg-go catalog patterns
   - add the standardized endpoint constants and honor endpoint discovery 
through `ConfigResponse.endpoints`
   - implement the exact request and response wire models from the REST OpenAPI
   - use the existing `udf` metadata model and builder rather than introducing 
a second metadata representation
   - preserve the specification's atomic metadata update and 
overload/version-history semantics
   - map standardized errors for missing namespaces/functions, already-existing 
functions, conflicts, invalid requests, and unsupported operations
   - implement any specified concurrency controls, preconditions, and 
idempotency behavior
   - add unit coverage for successful writes, validation failures, error 
mapping, endpoint negotiation, concurrent/conflicting updates, and 
round-tripping written metadata through `LoadFunction`
   - add documentation and examples for the supported catalog operations
   
   The public Go API should be designed from the final standardized operations 
rather than assuming in advance that the REST surface will use a particular set 
of create/replace/drop methods.


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