rdblue commented on code in PR #16400:
URL: https://github.com/apache/iceberg/pull/16400#discussion_r3276989183
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1217,6 +1217,56 @@ paths:
5XX:
$ref: '#/components/responses/ServerErrorResponse'
+ /v1/{prefix}/namespaces/{namespace}/tables/{table}/unregister:
+ parameters:
+ - $ref: '#/components/parameters/prefix'
+ - $ref: '#/components/parameters/namespace'
+ - $ref: '#/components/parameters/table'
+
+ post:
+ tags:
+ - Catalog API
+ summary: Unregister a table without removing its data or metadata files
+ operationId: unregisterTable
+ parameters:
+ - $ref: '#/components/parameters/idempotency-key'
+ description:
+ Unregister a table from the catalog. This is the opposite of
+ `registerTable`. The table no longer exists in the catalog, but the
+ underlying data and metadata files are left in place so that the table
+ can be registered in another catalog.
Review Comment:
This seems unnecessary to me. The `DELETE` request is called `dropTable` and
the semantics of dropping a table are clear in most SQL systems and are no
different in this spec. The purge flag is also already correct: it signals
whether the caller requested a purge; how to interpret that is not dictated by
the spec.
In addition, this description already calls out the relevant parts: that
data and metadata are left in place so they can be registered in another
catalog.
I think this is another example of "less is more" in our specs. If we were
to call out that "unlike drop" this doesn't delete data and metadata, we're
making the requirements more confusing because we don't specify when data
should be deleted (if at all) for `DROP`. It may seem like a good idea to point
out how this differs from drop, but I think the specification is more clear if
this focuses on the correct behavior of this endpoint and let the drop
documentations focus on its correct behavior.
--
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]
