[ 
https://issues.apache.org/jira/browse/CALCITE-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Hyde updated CALCITE-7073:
---------------------------------
    Description: 
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}}.

  was:
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.

[This PR|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:
{{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>'}}

This demonstrates that {{UNBASE64}} *erroneously defaults* to the type 
{{{}OTHER{}}}.


> 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
>
> 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)

Reply via email to