yyanyy commented on code in PR #57585:
URL: https://github.com/apache/spark/pull/57585#discussion_r3856210463
##########
sql/catalyst/src/main/java/org/apache/spark/sql/connector/catalog/RelationCatalog.java:
##########
@@ -134,6 +139,34 @@ public interface RelationCatalog extends TableCatalog,
ViewCatalog {
*/
Relation loadRelation(Identifier ident) throws NoSuchTableException;
+ /**
+ * Load the relation for an identifier that may resolve to either a table or
a view, forwarding
+ * the user-specified options that may affect table state.
+ * <p>
+ * Behaves like {@link #loadRelation(Identifier)} but also receives
table-state options. The
Review Comment:
My main concern with requiring the state-aware `loadTable` path is that, for
reads carrying state options, it reintroduces the exact table-first /
view-second fallback that `RelationCatalog` was added to avoid. It also forces
a state-aware `RelationCatalog` implementation back through a table-specific
API instead of allowing it to implement the unified lookup directly.
I think a better model would be `loadRelation(Identifier, RelationContext)`.
Today, that context would contain only the options projected through
`TableCatalog.tableStateOptionKeys()`. Those options would apply only if the
result is a `Table` and must be ignored if the result is a `View`. If Spark
later introduces view-state options, e.g. to select a version or branch of a
view definition, we could add a separate `viewStateOptions` field, projected
through a corresponding `ViewCatalog` declaration. The unified call could carry
both typed fields and let the catalog apply the one matching the resolved
relation kind, preserving the single lookup without conflating table and view
state.
--
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]
