bmorck commented on code in PR #17499:
URL: https://github.com/apache/iceberg/pull/17499#discussion_r3755185324
##########
spark/v4.1/spark-extensions/src/main/scala/org/apache/spark/sql/catalyst/analysis/ResolveViews.scala:
##########
@@ -111,16 +119,72 @@ case class ResolveViews(spark: SparkSession) extends
Rule[LogicalPlan] with Look
// Apply the field aliases and column comments
// This logic differs from how Spark handles views in
SessionCatalog.fromCatalogTable.
- // This is more strict because it doesn't allow resolution by field name.
+ // BINDING is more strict because it doesn't allow resolution by field
name. COMPENSATION and
+ // TYPE_EVOLUTION coerce as SessionCatalog.castColToType does for those
modes. Every mode keeps
+ // the stored name and metadata; only the coercion differs.
+ val mode = viewSchemaMode
val aliases = view.schema.fields.zipWithIndex.map { case (expected, pos) =>
val attr = GetColumnByOrdinal(pos, expected.dataType)
- Alias(UpCast(attr, expected.dataType), expected.name)(explicitMetadata =
- Some(expected.metadata))
+ val coerced =
+ if (mode == SparkSQLProperties.VIEW_SCHEMA_MODE_COMPENSATION) {
+ Cast(attr, expected.dataType, ansiEnabled = true)
+ } else if (mode == SparkSQLProperties.VIEW_SCHEMA_MODE_TYPE_EVOLUTION)
{
+ attr
Review Comment:
The existing `TYPE EVOLUTION` feature in Spark's V1 Session catalog views
also can create the same drift between stored schema and output type, so there
is precedent at least. But open to dissent here
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
