Skip to content

Conversation

@cloud-fan
Copy link
Contributor

@cloud-fan cloud-fan commented Dec 11, 2025

What changes were proposed in this pull request?

This PR aims to refactor the code that blocks time and geo types.

Why are the changes needed?

code unification

Does this PR introduce any user-facing change?

no

How was this patch tested?

existing tests

Was this patch authored or co-authored using generative AI tooling?

no

}

create.tableSchema.foreach(f => TypeUtils.failWithIntervalType(f.dataType))
TypeUtils.failUnsupportedDataType(create.tableSchema, SQLConf.get)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit off topic, but just follow how we block interval type for v2 catalogs, which we don't have any builtin impl in Spark yet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you use a new JIRA ID instead of a follow-up, @cloud-fan ?

@cloud-fan cloud-fan changed the title [SPARK-54609][SQL][FOLLOWUP] Unify geo and time types blocking [SPARK-54683][SQL] Unify geo and time types blocking Dec 11, 2025
createDeserializerForInstant(path)
case LocalDateTimeEncoder =>
createDeserializerForLocalDateTime(path)
case LocalTimeEncoder if !SQLConf.get.isTimeTypeEnabled =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this missed before? Or a side-effect of unification (which becomes to miss in other layer)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's missed before and I found it when trying to unify the geo type blocking code.

case TimestampEncoder(false) => createSerializerForSqlTimestamp(input)
case InstantEncoder(false) => createSerializerForJavaInstant(input)
case LocalDateTimeEncoder => createSerializerForLocalDateTime(input)
case LocalTimeEncoder if !SQLConf.get.isTimeTypeEnabled =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto.

case LocalDateTimeEncoder =>
createDeserializerForLocalDateTime(path)
case LocalTimeEncoder if !SQLConf.get.isTimeTypeEnabled =>
throw org.apache.spark.sql.errors.QueryCompilationErrors.unsupportedTimeTypeError()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we import org.apache.spark.sql.errors.QueryCompilationErrors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

geo type blocking does not import org.apache.spark.sql.AnalysisException either...

It's temporary and will be removed after we complete time type development. I think it's fine.

case InstantEncoder(false) => createSerializerForJavaInstant(input)
case LocalDateTimeEncoder => createSerializerForLocalDateTime(input)
case LocalTimeEncoder if !SQLConf.get.isTimeTypeEnabled =>
throw org.apache.spark.sql.errors.QueryCompilationErrors.unsupportedTimeTypeError()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto. import org.apache.spark.sql.errors.QueryCompilationErrors?

@dongjoon-hyun
Copy link
Member

Could you fix the compilation error, @cloud-fan ?

@dongjoon-hyun
Copy link
Member

Given the current status, I believe we are able to merge this as 4.1.1 instead of blocking 4.1.0-rc3.

I'm going to proceed toward RC3 from the AS-IS branch-4.1, @cloud-fan . Thank you for helping the release.

@cloud-fan
Copy link
Contributor Author

yea it doesn't block 4.1 RC as time type is mostly blocked and users won't be able to use it in any meaningful workloads.

@dongjoon-hyun
Copy link
Member

Thank you, @cloud-fan .

@cloud-fan
Copy link
Contributor Author

The test failure in SQLAppStatusListenerMemoryLeakSuite is unrelated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants