functions params should be implicitly cast to wider type #3791
Labels
Comments
big-andy-coates
added
enhancement
user-defined-functions
big-andy-coates
added a commit
to big-andy-coates/ksql
that referenced
this issue
Nov 7, 2019
This change sees `GenericRowValueTypeEnforcer` removed from the code base. It's being removed as the functionality it provides is: 1. Not needed in the production code path as values are always of the right type. 1. Only needed for a few tests to pass, (which have been fixed up). 1. It supports coercing between types which are outside of KSQLs implicit casting rules, e.g. coerce String -> BIGINT. We should support implicitly casting parameters to functions to wider types, as defined by KSQLs implicit casting rules. However, this is not currently the case. See confluentinc#3791.
2 tasks
big-andy-coates
added a commit
that referenced
this issue
Nov 7, 2019
This change sees `GenericRowValueTypeEnforcer` removed from the code base. It's being removed as the functionality it provides is: 1. Not needed in the production code path as values are always of the right type. 1. Only needed for a few tests to pass, (which have been fixed up). 1. It supports coercing between types which are outside of KSQLs implicit casting rules, e.g. coerce String -> BIGINT. We should support implicitly casting parameters to functions to wider types, as defined by KSQLs implicit casting rules. However, this is not currently the case. See #3791.
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
KSQL has rules for what types can be implicitly converted to a wider type, e.g
INTcan be implicitly converted toBIGINT. These rules are encapsulated inSqlBaseType.canImplicitlyCastand used byDefaultSqlValueCoercer.Rules are that the following implicit casts are possible:
INT->BIGINT->DECIMAL->DOUBLE.(Yes, the
DECIMAL->DOUBLEis potentially lossy, but that's outside the scope of this issue).The function framework does not support implicitly casting a parameter to a wider type. For example, the
expfunction can take aDOUBLEbut there is not a variant that takes aDECIMAL. At the moment is you try and call exp with aDECIMALit fails with an error. What is should do is use the implicit casting rules to widen theDECIMALto aDOUBLEand call the double version.Note: it looks like at some point that
GenericRowValueTypeEnforcermight have done this conversion, though it doesn't enforce the same rules on what can be implicitly cast. Also, I'm about to remove it.The text was updated successfully, but these errors were encountered: