xndai commented on code in PR #16400:
URL: https://github.com/apache/iceberg/pull/16400#discussion_r3277869618
##########
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:
> the semantics of dropping a table are clear in most SQL systems
True for the traditional DBs, but not so for the data lake engines. Both AWS
Redshift and AWS Athena do not purge table data when running `DROP TABLE`.
Apache Spark also says for external table, `DROP TABLE` is merely a metadata
operation.
I am afraid that if we don't call out the semantics of `purgeRequested`
clearly, people might face catastrophic data loss when they interpret
`purgeRequested = false` in a wrong way.
##########
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:
> the semantics of dropping a table are clear in most SQL systems
True for the traditional DBs, but not so for the data lake engines. Both AWS
Redshift and AWS Athena do not purge table data when running `DROP TABLE`.
Apache Spark also says for external table, `DROP TABLE` is merely a metadata
operation.
I am afraid that if we don't call out the semantics of `purgeRequested`
clearly, people might face catastrophic data loss when they interpret
`purgeRequested = false` in a wrong way.
--
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]
