You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Igor Seliverstov (Jira)" <ji...@apache.org> on 2021/11/03 10:12:00 UTC
[jira] [Updated] (CALCITE-4873) Unconditional operand appending on
SqlPosixRegexOperator#createCall method call
[ https://issues.apache.org/jira/browse/CALCITE-4873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Seliverstov updated CALCITE-4873:
--------------------------------------
Description:
We tried to use POSIX match syntax in our project and noticed unexpected behaviour on query validation in case the query contains SqlPosixRegexOperator.
SqlPosixRegexOperator#createCall implementation appends a case sensitivity flag even in case when the fag is already in place, it causes NPE on query validation.
the flow looks so:
1) SqlPosixRegexOperator is created by parser, sensitivity flag is added
2) At validation time when the validator tries to expand expression, the operator is created once again using original operands (which already contain sensitivity flag):
{noformat}
createCall:88, SqlPosixRegexOperator (org.apache.calcite.sql.fun)
result:117, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
result:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
visitScoped:5918, SqlValidatorImpl$Expander (org.apache.calcite.sql.validate)
visit:50, SqlScopedShuttle (org.apache.calcite.sql.validate)
visit:33, SqlScopedShuttle (org.apache.calcite.sql.validate)
accept:139, SqlCall (org.apache.calcite.sql)
expand:5493, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateWhereClause:4083, SqlValidatorImpl (org.apache.calcite.sql.validate)
{noformat}
at this point of time the call contains two boolean operands in operand set
3) At type derivation time the operator tries to lookup the original operand but fails because of the parameter count filter:
{noformat}
lookupSubjectRoutines:499, SqlUtil (org.apache.calcite.sql)
lookupRoutine:443, SqlUtil (org.apache.calcite.sql)
deriveType:525, SqlOperator (org.apache.calcite.sql)
deriveType:148, SqlBinaryOperator (org.apache.calcite.sql)
visit:5766, SqlValidatorImpl$DeriveTypeVisitor (org.apache.calcite.sql.validate)
visit:5753, SqlValidatorImpl$DeriveTypeVisitor (org.apache.calcite.sql.validate)
accept:139, SqlCall (org.apache.calcite.sql)
deriveTypeImpl:1753, SqlValidatorImpl (org.apache.calcite.sql.validate)
deriveType:1738, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateWhereOrOn:4099, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateWhereClause:4085, SqlValidatorImpl (org.apache.calcite.sql.validate)
{noformat}
The problematic query:
{noformat}
SELECT * FROM Student WHERE first_name ~ 'Mish%';
{noformat}
was:
We tried to use POSIX match syntax in our project and noticed unexpected behaviour on query validation in case the query contains SqlPosixRegexOperator.
SqlPosixRegexOperator#createCall implementation appends a case sensitivity flag even in case when the fag is already in place, it causes NPE on query validation.
the flow looks so:
1) SqlPosixRegexOperator is created by parser, sensitivity flag is added
2) At validation time when the validator tries to expand expression, the operator is created once again using original operands (which already contain sensitivity flag):
{noformat}
createCall:88, SqlPosixRegexOperator (org.apache.calcite.sql.fun)
result:117, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
result:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
visitScoped:5918, SqlValidatorImpl$Expander (org.apache.calcite.sql.validate)
visit:50, SqlScopedShuttle (org.apache.calcite.sql.validate)
visit:33, SqlScopedShuttle (org.apache.calcite.sql.validate)
accept:139, SqlCall (org.apache.calcite.sql)
expand:5493, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateWhereClause:4083, SqlValidatorImpl (org.apache.calcite.sql.validate)
{noformat}
at this point of time the call contains two boolean operands in operand set
3) At type derivation time the operator tries to lookup the original operand but fails because of the parameter count filter:
{noformat}
lookupSubjectRoutines:499, SqlUtil (org.apache.calcite.sql)
lookupRoutine:443, SqlUtil (org.apache.calcite.sql)
deriveType:525, SqlOperator (org.apache.calcite.sql)
deriveType:148, SqlBinaryOperator (org.apache.calcite.sql)
visit:5766, SqlValidatorImpl$DeriveTypeVisitor (org.apache.calcite.sql.validate)
visit:5753, SqlValidatorImpl$DeriveTypeVisitor (org.apache.calcite.sql.validate)
accept:139, SqlCall (org.apache.calcite.sql)
deriveTypeImpl:1753, SqlValidatorImpl (org.apache.calcite.sql.validate)
deriveType:1738, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateWhereOrOn:4099, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateWhereClause:4085, SqlValidatorImpl (org.apache.calcite.sql.validate)
{noformat}
> Unconditional operand appending on SqlPosixRegexOperator#createCall method call
> -------------------------------------------------------------------------------
>
> Key: CALCITE-4873
> URL: https://issues.apache.org/jira/browse/CALCITE-4873
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
> Reporter: Igor Seliverstov
> Priority: Major
>
> We tried to use POSIX match syntax in our project and noticed unexpected behaviour on query validation in case the query contains SqlPosixRegexOperator.
> SqlPosixRegexOperator#createCall implementation appends a case sensitivity flag even in case when the fag is already in place, it causes NPE on query validation.
> the flow looks so:
> 1) SqlPosixRegexOperator is created by parser, sensitivity flag is added
> 2) At validation time when the validator tries to expand expression, the operator is created once again using original operands (which already contain sensitivity flag):
> {noformat}
> createCall:88, SqlPosixRegexOperator (org.apache.calcite.sql.fun)
> result:117, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> result:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitScoped:5918, SqlValidatorImpl$Expander (org.apache.calcite.sql.validate)
> visit:50, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:33, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:139, SqlCall (org.apache.calcite.sql)
> expand:5493, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateWhereClause:4083, SqlValidatorImpl (org.apache.calcite.sql.validate)
> {noformat}
> at this point of time the call contains two boolean operands in operand set
> 3) At type derivation time the operator tries to lookup the original operand but fails because of the parameter count filter:
> {noformat}
> lookupSubjectRoutines:499, SqlUtil (org.apache.calcite.sql)
> lookupRoutine:443, SqlUtil (org.apache.calcite.sql)
> deriveType:525, SqlOperator (org.apache.calcite.sql)
> deriveType:148, SqlBinaryOperator (org.apache.calcite.sql)
> visit:5766, SqlValidatorImpl$DeriveTypeVisitor (org.apache.calcite.sql.validate)
> visit:5753, SqlValidatorImpl$DeriveTypeVisitor (org.apache.calcite.sql.validate)
> accept:139, SqlCall (org.apache.calcite.sql)
> deriveTypeImpl:1753, SqlValidatorImpl (org.apache.calcite.sql.validate)
> deriveType:1738, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateWhereOrOn:4099, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateWhereClause:4085, SqlValidatorImpl (org.apache.calcite.sql.validate)
> {noformat}
> The problematic query:
> {noformat}
> SELECT * FROM Student WHERE first_name ~ 'Mish%';
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)