[
https://issues.apache.org/jira/browse/TAJO-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14064910#comment-14064910
]
ASF GitHub Bot commented on TAJO-939:
-------------------------------------
Github user jihoonson commented on a diff in the pull request:
https://github.com/apache/tajo/pull/71#discussion_r15056936
--- Diff:
tajo-core/src/main/java/org/apache/tajo/engine/planner/nameresolver/NameResolvingMode.java
---
@@ -0,0 +1,80 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.tajo.engine.planner.nameresolver;
+
+/**
+ *
+ * <h2>Motivation</h2>
+ *
+ * Please take a look at the following example query:
+ *
+ * <pre>
+ * select (l_orderkey + l_orderkey) l_orderkey from lineitem where
l_orderkey > 2 order by l_orderkey;
+ * </pre>
+ *
+ * Although <code>l_orderkey</code> seems to be ambiguous, the above
usages are available in commercial DBMSs.
+ * In order to eliminate the ambiguity, Tajo follows the behaviors of
PostgreSQL.
+ *
+ * <h2>Resolving Modes</h2>
+ *
+ * From the behaviors of PostgreSQL, we found that there are three kinds
of name resolving modes.
+ * Each definition is as follows:
+ *
+ * <ul>
+ * <li><b>RELS_ONLY</b> finds a column from the relations in the current
block.
+ * <li><b>RELS_AND_SUBEXPRS</b> finds a column from the all relations in
the current block and
+ * from aliased temporal fields; a temporal field means an explicitly
aliased expression. If there are duplicated
+ * columns in the relation and temporal fields, this level firstly
chooses the field in a relation.</li>
+ * <li><b>SUBEXPRS_AND_RELS</b> is very similar to
<code>RELS_AND_SUBEXPRS</code>. The main difference is that it
+ * firstly chooses an aliased temporal field instead of the fields in a
relation.</li>
+ * </ul>
+ *
+ * <h2>The relationship between resolving modes and operators</h3>
+ *
+ * <ul>
+ * <li>fields in select list are resolved in the REL_ONLY mode.</li>
+ * <li>fields in WHERE clause are resolved in the RELS_AND_SUBEXPRS
mode.</li>
+ * <li>fields in GROUP BY, HAVING, ORDER BY, and LIMIT are resolved in
the SUBEXPRS_AND_RELS mode.</li>
--- End diff --
As you commented, fields in LIMIT are resolved in the REL_ONLY mode. Please
fix it.
> Refactoring the column resolver in LogicalPlan
> ----------------------------------------------
>
> Key: TAJO-939
> URL: https://issues.apache.org/jira/browse/TAJO-939
> Project: Tajo
> Issue Type: Bug
> Components: planner/optimizer
> Reporter: Hyunsik Choi
> Assignee: Hyunsik Choi
> Fix For: 0.9.0
>
>
> The main role of the column resolver is to find the exact column in a
> relation or a temporal column to which a variable name points. We have used a
> monolithic column resolver to deal with lots of cases.
> But, resolving a name should play different roles according to at which the
> name is placed.
> For example, 1) a column name in select list always points one of fields in
> relations, 2) a column name in WHERE clause can point to one of fields in
> relations or one of aliased temporal fields in select list. If there are
> duplicated, the column name firstly chooses the field in relations. 3) a
> column name in ORDER BY clause is similar to that in WHERE clause, but it
> firstly chooses one of aliased temporal fields in select list.
> The current column resolver does not consider the above rules. As a result,
> it works incorrectly in some cases where a sql statement includes the same
> name references, actually indicating one field in relation and one aliased
> temporal field in select list. We should fix it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
