New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SPARK-35975][SQL] New configuration spark.sql.timestampType
for the default timestamp type
#33176
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -44,6 +44,7 @@ import org.apache.spark.sql.catalyst.plans.logical.HintErrorHandler | |
import org.apache.spark.sql.catalyst.util.DateTimeUtils | ||
import org.apache.spark.sql.connector.catalog.CatalogManager.SESSION_CATALOG_NAME | ||
import org.apache.spark.sql.errors.{QueryCompilationErrors, QueryExecutionErrors} | ||
import org.apache.spark.sql.types.{AtomicType, TimestampNTZType, TimestampType} | ||
import org.apache.spark.unsafe.array.ByteArrayMethods | ||
import org.apache.spark.util.Utils | ||
|
||
|
@@ -2820,6 +2821,24 @@ object SQLConf { | |
.booleanConf | ||
.createWithDefault(true) | ||
|
||
object TimestampTypes extends Enumeration { | ||
val TIMESTAMP_NTZ, TIMESTAMP_LTZ = Value | ||
} | ||
|
||
val TIMESTAMP_TYPE = | ||
buildConf("spark.sql.timestampType") | ||
.doc("Configures the default timestamp type of Spark SQL, including SQL DDL and Cast " + | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The scope is bigger than this. It will affect timestamp literal, function There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder about types literals, for instance There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, I mentioned in #33176 (comment). The type literal logic with TIMESTAMP_NTZ:
|
||
s"clause. Setting the configuration as ${TimestampTypes.TIMESTAMP_NTZ.toString} will " + | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought the compiler automatically calls the |
||
"use TIMESTAMP WITHOUT TIME ZONE as the default type while putting it as " + | ||
s"${TimestampTypes.TIMESTAMP_LTZ.toString} will use TIMESTAMP WITH LOCAL TIME ZONE. " + | ||
"Before the 3.2.0 release, Spark only supports the TIMESTAMP WITH " + | ||
"LOCAL TIME ZONE type.") | ||
.version("3.2.0") | ||
.stringConf | ||
.transform(_.toUpperCase(Locale.ROOT)) | ||
.checkValues(TimestampTypes.values.map(_.toString)) | ||
.createWithDefault(TimestampTypes.TIMESTAMP_LTZ.toString) | ||
|
||
val DATETIME_JAVA8API_ENABLED = buildConf("spark.sql.datetime.java8API.enabled") | ||
.doc("If the configuration property is set to true, java.time.Instant and " + | ||
"java.time.LocalDate classes of Java 8 API are used as external types for " + | ||
|
@@ -3897,6 +3916,15 @@ class SQLConf extends Serializable with Logging { | |
|
||
def ansiEnabled: Boolean = getConf(ANSI_ENABLED) | ||
|
||
def timestampType: AtomicType = getConf(TIMESTAMP_TYPE) match { | ||
case "TIMESTAMP_LTZ" => | ||
// For historical reason, the TimestampType maps to TIMESTAMP WITH LOCAL TIME ZONE | ||
TimestampType | ||
|
||
case "TIMESTAMP_NTZ" => | ||
TimestampNTZType | ||
} | ||
|
||
def nestedSchemaPruningEnabled: Boolean = getConf(NESTED_SCHEMA_PRUNING_ENABLED) | ||
|
||
def serializerNestedSchemaPruningEnabled: Boolean = | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to support parsing type string for LTZ and NTZ specifically so that people can avoid relying on config in their queries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer doing that in separate PRs to keep this one clean. We should support the new keyword both on data type parsing and the type literals.
https://issues.apache.org/jira/browse/SPARK-35977
https://issues.apache.org/jira/browse/SPARK-35978