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

Tuomas Kiviaho commented on CALCITE-5366:
-----------------------------------------

{code:sql}
SELECT * 
FROM TABLE(MySchema.MyTableMacro(NonOptC => 'foo', NonOptD => 'bar')
{code}

The above doesn't resolve but the below does

{code:sql}
SELECT * 
FROM TABLE(MySchema.MyTableMacro(OptA => DEFAULT, OptB=> DEFAULT, NonOptC => 
'foo', NonOptD => 'bar')
{code}

Another weird thing is that even when I have {{MySchema}} as default I end up 
with assertion error when I do not fully declare the reference to the table 
macro.

> 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)

Reply via email to