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

Julian Hyde commented on CALCITE-6939:
--------------------------------------

It seems that the industry has gone with left-to-right. Even though I think 
that's a bad idea, we should support it. I'm glad that Mihai added it as a 
conformance mode.

I am worried about the validator doing the expansion. We have had many bugs 
caused by expansion (e.g. matching columns to GROUP BY columns). I think that 
validation could take place without expansion (name resolution, and then type 
deduction, by following pointers) and then SQL-to-rel conversion could, again, 
follow pointers. Could logic perhaps be included in the namespace rather than 
the validator?

> Add support for Lateral Column Alias
> ------------------------------------
>
>                 Key: CALCITE-6939
>                 URL: https://issues.apache.org/jira/browse/CALCITE-6939
>             Project: Calcite
>          Issue Type: Wish
>          Components: core
>    Affects Versions: 1.39.0
>            Reporter: Mihai Budiu
>            Priority: Minor
>              Labels: pull-request-available
>
> Several SQL dialects allow a SELECT to refer to aliases introduced previously 
> in the same select.
> Examples are: Spark, BigQuery, Snowflake. Other names for this feature are 
> "column aliasing with immediate reference", or "column alias visibility in 
> the same SELECT statement".
> This feature was already proposed and implemented by [CALCITE-5248], but that 
> issue and PR contains multiple other unrelated features. 
> I am also proposing adding a conformance flag `isSelectAlias` which enables 
> this feature. This is strictly a validator feature.
> The semantics has to be clearly defined; we do not want to change the 
> semantics of any existing query. My proposal is to allow a name to be 
> resolved in the current SELECT statement only if all the other name lookup 
> methods have failed. 
> I also think it's a good idea to introduce new aliases from left to right, so 
> a expression can only refer to aliases introduced to the left of it. This 
> removes a few unpleasant corner cases too.
> Another difficult problem is the handling of nondeterministic expressions. 
> When you refer to a prior expression by an alias, can/is the expression 
> re-evaluated? Unfortunately I believe that the current Calcite IR makes it 
> difficult to represent the program in such a way that re-evaluation is 
> avoided. (But this is a problem with many other Calcite rewrite rules as 
> well.) This feature is still useful when applied to deterministic expressions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to