Query engine
Trino version 481
Question
Hi,
recently I have been playing around with several implementations of REST Catalog and I noticed that not everybody follows the spec when it comes to purgeRequested flag in RESTSessionCatalog#dropTable(SessionContext, TableIdentifier). This specifically affects how unregister_table procedure behaves in Trino which calls that dropTable method.
For example Lakekeeper sets default value of purgeRequested to true meaning calling unregisted_table ,which by documentation and definition should only affect metadata and keep the data untouched, results in deleting data and can cause accidental data loss if someone migrated from one REST catalog implementation to another and expected the procedure the behave the same.
As I'm fairly new to iceberg I would like to hear what the consensus is on that behaviour. Should the difference between purgeTable and dropTable be up to catalogs implementation?
Query engine
Trino version 481
Question
Hi,
recently I have been playing around with several implementations of REST Catalog and I noticed that not everybody follows the spec when it comes to
purgeRequestedflag inRESTSessionCatalog#dropTable(SessionContext, TableIdentifier). This specifically affects howunregister_tableprocedure behaves in Trino which calls thatdropTablemethod.For example Lakekeeper sets default value of
purgeRequestedtotruemeaning callingunregisted_table,which by documentation and definition should only affect metadata and keep the data untouched, results in deleting data and can cause accidental data loss if someone migrated from one REST catalog implementation to another and expected the procedure the behave the same.As I'm fairly new to iceberg I would like to hear what the consensus is on that behaviour. Should the difference between purgeTable and dropTable be up to catalogs implementation?