Github user gatorsmile commented on the issue: https://github.com/apache/spark/pull/14638 @jamartinh I got your point. Hive tables can be read/wrote by both Hive and Spark. Ideally, we should respect all the features supported by Hive. That means, if the metadata of an existing Hive table already has such a `TBLPROPERTIES`, we should not simply ignore it. However, when users want to add it in Spark side, what is the right interface? In the existing Spark SQL, table properties are not used for such purposes. When users specify the table-level properties/options for data source tables, we store them in the storage property. Thus, they will not be recognized by Hive. We might need to hold it until we figure out how to unify the SQL interfaces of Hive tables and the other data source tables. `TBLPROPERTIES` is not the right interface for us, at least now.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- --------------------------------------------------------------------- To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org For additional commands, e-mail: reviews-h...@spark.apache.org