[
https://issues.apache.org/jira/browse/CALCITE-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17035726#comment-17035726
]
Rui Wang commented on CALCITE-3788:
-----------------------------------
Seems like the SCALAR_QUERY setup is used to handle such case:
{code:sql}
select A.department_id
from foodmart.employee A
where A.department_id = ( select min( A.department_id) from foodmart.department
B where 1=2 )";
{code}
So only check SqlSelect is not enough. Ideally the SqlSelect should tell us if
it returns a scalar value or not. But I think it will be very difficult to do
so.
> SqlValidatorImpl.registerOperandSubQueries should skip creating SCALAR_QUERY
> call when operand is a SqlSelect
> -------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-3788
> URL: https://issues.apache.org/jira/browse/CALCITE-3788
> Project: Calcite
> Issue Type: Sub-task
> Reporter: Rui Wang
> Assignee: Rui Wang
> Priority: Major
>
> For a table function which uses named argument for a TABLE parameter:
> Select * From
> TABLE(TUMBLE(
> data => TABLE orders
> ...
> )
> The TABLE parameter will be wrapped by a SCALAR_QUERY call at this line:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L3067
> However, it is wrong because TABLE paramter is not a query that returns a
> scalar value.
> It cannot be solved by overriding SqlOperator.argumentMustBeScalar because
> named argument is a special operator that doesn't tied with other operators.
> One possible resolution is also check if operand is SqlSelect at
> SqlValidatorImpl.java#L3067.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
