pan3793 commented on issue #3845: URL: https://github.com/apache/kyuubi/issues/3845#issuecomment-5728798849
@attilapiros, thanks for the investigation. I took a closer look at the Databricks docs, and figured out why `SELECT` and `MODIFY` are more appropriate here. https://docs.databricks.com/gcp/en/sql/language-manual/sql-ref-syntax-ddl-create-table-using#parameters > REPLACE > > If specified, replaces the table and its content if it already exists. This clause is only supported > for Delta and Apache Iceberg tables. > > REPLACE preserves the [table history](https://docs.databricks.com/gcp/en/tables/history) and granted privileges, row filters, and column masks. In OSS Spark, `CREATE OR REPLACE` is not allowed for v1 tables; and for v2 tables, if the data source implements the `StagingTableCatalog`, it calls `StagingTableCatalog#stageReplace` (connector implementation-dependent), otherwise, it performs `DROP` then `CREATE`. So, we can check `CREATE` and `DROP`/`ALTER`(or something similar to `MODIFY`) based on whether the type connector implements `StagingTableCatalog` if we can distinguish that, otherwise, I would follow Databricks Unity Catalog behavior given that the mainstream lakehouse table formats (iceberg, delta) would implement `StagingTableCatalog`. -- 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]
