juliuszsompolski commented on a change in pull request #29539:
URL: https://github.com/apache/spark/pull/29539#discussion_r478242844
##########
File path:
sql/hive-thriftserver/src/test/scala/org/apache/spark/sql/hive/thriftserver/HiveThriftServer2Suites.scala
##########
@@ -686,6 +686,23 @@ class HiveThriftBinaryServerSuite extends
HiveThriftJdbcTest {
}
}
+ test("Query Intervals in VIEWs through thrift server") {
+ val viewName1 = "view_interval_1"
+ val viewName2 = "view_interval_2"
+ val ddl1 = s"CREATE GLOBAL TEMP VIEW $viewName1 AS SELECT INTERVAL 1 DAY
AS i"
+ val ddl2 = s"CREATE TEMP VIEW $viewName2 as select * from
global_temp.$viewName1"
+ withJdbcStatement(viewName1, viewName2) { statement =>
+ statement.executeQuery(ddl1)
+ statement.executeQuery(ddl2)
+ val rs = statement.executeQuery(s"SELECT v1.i as a, v2.i as b FROM
global_temp.$viewName1" +
Review comment:
It would be the most consistent if the table columns metadata, and
metadata of the result of `select * from table` had consistent types. I don't
really have a preference whether it should be string or interval. Last year the
discussion leaned towards string, because of the intervals not really being
standard compliant, but indeed there might be value in having it marked as
interval in the schema, so the application might try to parse it as such...
Though, e.g. between Spark 2.4 and Spark 3.0 the format of the returned
interval changed, see https://issues.apache.org/jira/browse/SPARK-32132, which
might have broken how anyone would have parsed it, so Spark is not really
giving any guarantees as to the stability of the format of this type...
Ultimately, I think this is very rarely used, as intervals didn't even work
at all until https://github.com/apache/spark/pull/25277 and it was not raised
earlier...
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
