[
https://issues.apache.org/jira/browse/CALCITE-5479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678460#comment-17678460
]
Julian Hyde commented on CALCITE-5479:
--------------------------------------
Suppose you have a function "f(integer, timestamp)" and you want to create a
{{SqlOperandTypeChecker}} to validate a call to {{f}}. You create a
{{SqlSingleOperandTypeChecker}} instance for each parameter, let's call them
{{i}} and {{t}}, and bind them together using
{{OperandTypes.sequence("f(integer, timestamp)", i, t}} (which creates a
{{CompositeOperandTypeChecker}}).
Those checkers, {{i}} and {{t}} will be invoked with the same
{{SqlCallBinding}} object. But how does {{i}} know that it is being asked to
verify operand 0, and how does {{t}} know that it is being asked to verify
operand 1?
As far as I can tell, that's what the {{iFormalOperand}} parameter was intended
for.
I needed it for something (I forget, details in the commit), I tried to restore
it to its previous purpose, stuff broke, I tried to paper over the cracks.
I can't see any good reason why {{iFormalOperand}} should always be zero, or
why any code should rely on it being zero. (I mean, why have a parameter that
is always zero?!) But I haven't had time to delve into the details.
> Restore consistent handling of iFormalOperand in sequence checkers
> ------------------------------------------------------------------
>
> Key: CALCITE-5479
> URL: https://issues.apache.org/jira/browse/CALCITE-5479
> Project: Calcite
> Issue Type: Bug
> Reporter: Gian Merlino
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Handling for {{OperandTypes.sequence}} changed in
> [33f4ab40bbee26e06209061c35a422f2f1e05371|https://github.com/apache/calcite/commit/33f4ab40bbee26e06209061c35a422f2f1e05371#diff-b0b8d58a792b8e60b9e97717912aecfc6695536f5026ac4d5231d14e34b91566L303-R316]
> such that {{iFormalOperand}} passed to subcheckers is no longer always zero,
> but is instead:
> - Zero if the subchecker is {{FamilyOperandTypeChecker}}.
> - Otherwise, the operand number in the overall sequence.
> It causes problems for the way we're using sequence checkers in Druid, since
> we don't always use {{FamilyOperandTypeChecker}}, but we _do_ assume the old
> behavior: that {{iFormalOperand}} is always zero, and therefore we can put
> any checker into the sequence without it being "aware" that it is in a
> sequence.
> I marked this as a bug in case this change was made accidentally. If it was
> made for a reason, please let me know. Thanks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
