[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139433#comment-15139433 ] Julian Hyde commented on CALCITE-1062: -- I took a quick look, looks good. I'm going to test it and do some fix up (I think we should have a SqlKind value for ROW_NUMBER, and I'd like to convert the various filterOperatorXxx methods to use Iterators.filter) but I think your PR is sound. > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139920#comment-15139920 ] Julian Hyde commented on CALCITE-1062: -- Ah, I found it. The stack got deeper because SqlOperator.deriveType no longer calls deriveType on each operand. It is a bit more work to call deriveType early, but keeps the stack smaller, so I restored it. I also discovered CALCITE-1083, which was causing an O(n ^ 2) slow-down (but not affecting stack-size). > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139976#comment-15139976 ] Sean Hsuan-Yi Chu commented on CALCITE-1062: I see. Thanks for helping point out that issue! > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15131031#comment-15131031 ] Julian Hyde commented on CALCITE-1062: -- * I no longer think it needs to be in SqlOperatorTable. But I think you should unify lookupSqlOperator with lookupRoutine. Generalize lookupRoutine to handle SqlOperator, rather than copy-pasting. You could add a type parameter "" if you like. * Would it be possible to move SqlFunction.deriveType up to SqlOperator? The methods are essentially doing the same thing. * Use StringBuilder not StringBuffer. In fact for that particular case, just use + * Use plural name for collections: rename operatorType to operatorTypes. * Remove the 'toUpperCase' hack. The core is case-sensitive. * Any reason your test cannot be in the base class SqlOperatorBaseTest? It should be obvious that test cases shouldn't be defined in CalciteSqlOperatorTest. * Use assertThat, not assertEquals > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15125550#comment-15125550 ] Julian Hyde commented on CALCITE-1062: -- How about extending the capabilities of SqlOperatorTable so that it can resolve overloading in operators not just functions? > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122288#comment-15122288 ] Julian Hyde commented on CALCITE-1062: -- But why add all this new code? Anyone can supply a custom implementation of SqlOperatorTable and use it in the validator. That already works, AFAIK. > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122778#comment-15122778 ] Sean Hsuan-Yi Chu commented on CALCITE-1062: That is true for "SqlFunction" only. You could compare the bodies of SqlFunction.deriveType() and SqlOperator.deriveType(). While SqlFunction.deriveType() looks up an overriding operator from SqlOperatorTable, SqlOperator.deriveType() does not. > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
