[
https://issues.apache.org/jira/browse/CALCITE-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu updated CALCITE-6939:
---------------------------------
Description:
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.
was:
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-1306], 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.
> 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
>
> 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)
