[
https://issues.apache.org/jira/browse/CALCITE-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17632616#comment-17632616
]
Tuomas Kiviaho commented on CALCITE-5366:
-----------------------------------------
Thanks for the clarification since the assertion error lead me to believe that
I'd encountered something worth pointing out.
{code}
Warning: JDBC driver threw non-SQLException
java.lang.AssertionError
at org.apache.calcite.sql.parser.SqlParserPos.sum(SqlParserPos.java:232)
at
org.apache.calcite.sql.SqlIdentifier.getComponent(SqlIdentifier.java:238)
at org.apache.calcite.sql.SqlIdentifier.skipLast(SqlIdentifier.java:281)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertCollectionTable(SqlToRelConverter.java:2814)
{code}
I still wonder whether the assertion error is the best way to indicate this
especially when the Calcite SQL Grammar only states {{functionName}} and there
is no further BNF to indicate how it's formed.
Maybe the existence of required schema be tested earlier since there isn't much
else to be done about the situation at the execution time where the assertion
is currently forced upon.
{{ParseException}} feels to me like an ideal solution which would also clarify
the BNF.
> User defined function optional named arguments are required to be present
> -------------------------------------------------------------------------
>
> Key: CALCITE-5366
> URL: https://issues.apache.org/jira/browse/CALCITE-5366
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.32.0
> Reporter: Tuomas Kiviaho
> Priority: Major
>
> In situation where optional parameters are stated before the required ones
> the {{FamilyOperandTypeChecker#getOperandCountRange}} prohibits leaving these
> arguments undefined.
> Would it be possible to have {{getOperandCountRange}} reporting only the
> number of non-optional parameters in case named parameters are used.
> The current behavior might indeed be in line with SQL99 SQL:1999 Part 2
> Section 10.4 as the {{SqlUtil#lookupSubjectRoutines}} states, but the current
> behavior kind of beats the flexibility that named parameters provide.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
