drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paul-rogers <...@git.apache.org>
Subject [GitHub] drill pull request #736: DRILL-5238: CTTAS: unable to resolve temporary tabl...
Date Fri, 03 Feb 2017 17:59:57 GMT
Github user paul-rogers commented on a diff in the pull request:

    https://github.com/apache/drill/pull/736#discussion_r99388535
  
    --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/SqlConverter.java
---
    @@ -527,5 +529,31 @@ public RelOptTableImpl getTable(final List<String> names) {
           }
           return super.getTable(names);
         }
    +
    +    /**
    +     * Check if passed table is temporary or not should be done if:
    +     * <li>schema is not indicated (only one element in the names list)<li/>
    +     * <li>current schema or indicated schema is default temporary workspace<li/>
    +     *
    +     * Examples (where dfs.tmp is default temporary workspace):
    +     * <li>select * from t<li/>
    +     * <li>select * from dfs.tmp.t<li/>
    +     * <li>use dfs; select * from tmp.t<li/>
    +     *
    +     * @param names             list of schema and table names, table name is always
the last element
    +     * @param defaultSchemaPath current schema path set using USE command
    +     * @param drillConfig       drill config
    +     * @return true if check for temporary table should be done, false otherwise
    +     */
    +    private boolean checkForTemporaryTable(List<String> names, String defaultSchemaPath,
DrillConfig drillConfig) {
    +      if (names.size() == 1) {
    +        return true;
    +      }
    --- End diff --
    
    A single name might be a temporary table, or it might not be. Hence the name suggestion
above. Is the intent to simply apply a filter so that we separate out those that are not temporary
tables from those that may or may not be?
    
    If we want a positive check that this is, in fact, a temp table, wouldn't we have to resolve
the name against known temp tables rather than just infer based on path length?
    
    And, if we are just filtering out known non-temp tables, is that good enough for the use
case? That is, can the case we are fixing handle the ambiguous "may or may not be temporary"
case?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message