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
