paul-rogers commented on a change in pull request #2026: DRILL-7330: Implement
metadata usage for all format plugins
URL: https://github.com/apache/drill/pull/2026#discussion_r392631705
##########
File path:
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/scan/file/ImplicitColumnManager.java
##########
@@ -199,6 +192,21 @@ public ImplicitColumnManager(OptionSet optionManager,
}
}
+ /**
+ * Specifies whether to plan based on the legacy meaning of "*". See
+ * <a href="https://issues.apache.org/jira/browse/DRILL-5542";>DRILL-5542</a>.
+ * If true, then the star column <i>includes</i> implicit and partition
+ * columns. If false, then star matches <i>only</i> table columns.
+ *
+ * @param optionManager access to the options for this query; used
+ * too look up custom names for the metadata columns
+ * @param config implicit column options
+ */
+ public ImplicitColumnManager(OptionSet optionManager,
Review comment:
Help me understand your intent. Older Drill versions always expanded
implicit columns in wildcard queries. Then the project threw away those
columns. We changed this so that the user asks for the columns they want. We
could do this because Calcite changed (as I understand it) so that it will
allow a projection list of the form `SELECT *, filename`.
Does metadata need the implicit columns expanded for a wildcard query? Is
this the behavior for the other, non-EVF readers?
If so, we'll want to balance the needs of metadata (needs those columns) vs.
other queries (do not need them and don't want to pay the cost.)
----------------------------------------------------------------
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]
With regards,
Apache Git Services
