[
https://issues.apache.org/jira/browse/CALCITE-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17986567#comment-17986567
]
Lucas Brenner commented on CALCITE-7073:
----------------------------------------
Thank you [~julianhyde]! Do you have an expected date for the release this
commit will be included?
> If the Java return type of a UDF is ByteString, Calcite should deduce that
> the SQL type is VARBINARY
> ----------------------------------------------------------------------------------------------------
>
> Key: CALCITE-7073
> URL: https://issues.apache.org/jira/browse/CALCITE-7073
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Lucas Brenner
> Priority: Minor
> Labels: pull-request-available
> Fix For: 1.41.0
>
>
> If a Java user-defined function (UDF) has return type {{ByteString}}, Calcite
> should deduce that the SQL return type is {{VARBINARY}}.
> Calcite uses {{org.apache.calcite.avatica.util.ByteString}} internally to
> represent {{VARBINARY}}. However, when introducing a custom function that
> returns {{{}ByteString{}}}, such as {{UNBASE64}} (which decodes a Base64
> string to bytes), its return type defaults to {{OTHER}}. This occurs because
> there is no explicit mapping for {{ByteString}} in the
> {{JavaToSqlTypeConversionRules}} class.
> [PR 4440|https://github.com/apache/calcite/pull/4440] adds the necessary
> mapping.
> The added test {{testUnbase64DirectComparison}} provides a scenario where
> this bug occurs. If we remove the mapping introduced in the PR, we get the
> following error:
> {noformat}
> Error while executing SQL "select "adhoc".unbase64(cast('dGVzdA==' as
> varchar)) = x'74657374' as C
> ": From line 1, column 16 to line 1, column 66: Cannot apply '=' to arguments
> of type '<OTHER> = <BINARY(4)>'. Supported form(s): '<COMPARABLE_TYPE> =
> <COMPARABLE_TYPE>'
> {noformat}
> This demonstrates that {{UNBASE64}} *erroneously defaults* to the type
> {{OTHER}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
