[jira] [Commented] (SPARK-12725) SQL generation suffers from name conficts introduced by some analysis rules

["Cheng Lian (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SPARK-12725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15122013#comment-15122013 ] 

Cheng Lian commented on SPARK-12725:
------------------------------------

One possible solution I was thinking about is that we can add a new {{Attribute}} class named {{GeneratedAttributeRef}}, which is exactly the same as {{AttributeReference}} except that it's {{sql}} representation includes expression ID (e.g. {{gid_42}} instead of {{gid}}). To avoid code duplication, we can extract common code into an abstract class, say {{AbstractAttributeRef}}.

[~yhuai] [~rxin] [~marmbrus] What do you think? 

> SQL generation suffers from name conficts introduced by some analysis rules
> ---------------------------------------------------------------------------
>
>                 Key: SPARK-12725
>                 URL: https://issues.apache.org/jira/browse/SPARK-12725
>             Project: Spark
>          Issue Type: Sub-task
>          Components: SQL
>            Reporter: Cheng Lian
>
> Some analysis rules generate auxiliary attribute references with the same name but different expression IDs. For example, {{ResolveAggregateFunctions}} introduces {{havingCondition}} and {{aggOrder}}, and {{DistinctAggregationRewriter}} introduces {{gid}}.
> This is OK for normal query execution since these attribute references get expression IDs. However, it's troublesome when converting resolved query plans back to SQL query strings since expression IDs are erased.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org