[
https://issues.apache.org/jira/browse/CALCITE-5724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17737418#comment-17737418
]
Will Noble edited comment on CALCITE-5724 at 6/27/23 2:44 AM:
--------------------------------------------------------------
I think there's a better way. Between CALCITE-5044 and CALCITE-5510, the
behavior of {{SqlImplementor.Context.orderField}} went from simply copying the
expression from the select list, to this complex behavior:
# If the dialect is sort-by-ordinal and the expression is a literal integer,
convert it to a literal string, and sort by that string expression.
# If the dialect is sort-by-ordinal and the expression is a {{SqlBasicCall}},
sort by ordinal.
# Otherwise, sort by expression.
It seems like a much better state of affairs would be this:
# If the dialect is sort-by-ordinal, sort by ordinal.
# Otherwise, sort by expression.
Biasing ourselves more consistently toward sorting by ordinal like this causes
the rel-to-sql converter to generate more sub-queries, the logic for which was
recently fixed in CALCITE-5768. I have a hunch that bug was stopping someone
from implementing this seemingly-more-obvious solution in the first place.
was (Author: wnoble):
I think there's a better way. Between CALCITE-5044 and CALCITE-5510, the
behavior of {{SqlImplementor.Context.orderField}} went from simply copying the
expression from the select list, to this complex behavior:
# If the dialect is sort-by-ordinal and the expression is a literal integer,
convert it to a literal string.
# If the dialect is sort-by-ordinal and the expression is a {{SqlBasicCall}},
sort by ordinal.
# Otherwise, sort by expression.
It seems like a much better state of affairs would be this:
# If the dialect is sort-by-ordinal, sort by ordinal.
# Otherwise, sort by expression.
Biasing ourselves more consistently toward sorting by ordinal like this causes
the rel-to-sql converter to generate more sub-queries, the logic for which was
recently fixed in CALCITE-5768. I have a hunch that bug was stopping someone
from implementing this seemingly-more-obvious solution in the first place.
> Generated SQL uses literal values in ORDER BY clauses
> -----------------------------------------------------
>
> Key: CALCITE-5724
> URL: https://issues.apache.org/jira/browse/CALCITE-5724
> Project: Calcite
> Issue Type: Bug
> Reporter: Joey Moore
> Assignee: Joey Moore
> Priority: Major
> Labels: pull-request-available
>
> Current behavior in the SqlImplementor will generate SqlCharStringLiterals in
> ORDER BY fields when there is a Literal value in the SELECT clause. This
> happens in languages with isSortByOrdinal(). This leads to errors in dialects
> in which cannot have literal values in ORDER BY clauses such as BigQuery.
> Proposed fix is to use ordinals in all cases where a literal value is present
> in the SELECT clause.
> Example of current implementation:
> {code:java}
> select 3.14159265 as pi
> from \"product\"
> order by 1;
> {code}
> Will return
> {code:java}
> SELECT 3.14159265 AS \"PI\"
> FROM \"foodmart\".\"product\"
> ORDER BY '3.14159265'{code}
> Proposed implementation will return :
> {code:java}
> SELECT 3.14159265 AS \"PI\"
> FROM \"foodmart\".\"product\"
> ORDER BY 1{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
