[
https://issues.apache.org/jira/browse/DERBY-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523167
]
Mamta A. Satoor commented on DERBY-2910:
----------------------------------------
Kathey, thanks for picking up this bug. Your approach seems logical, ie have
internal CASTs pick up the current compilation schema's collation just as we do
for explicit CASTs. I wonder if the SQL spec says anything at all for such
implicit CASTs and their collation type. But from a user point of view, your
approach surely makes sense to me.
> SimpleStringOperatorNode in it's bindExpression method generates a character
> string CAST if required but does not set the correct collation.
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2910
> URL: https://issues.apache.org/jira/browse/DERBY-2910
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.1.4, 10.4.0.0
> Reporter: Mamta A. Satoor
> Assignee: Kathey Marsden
> Attachments: derby-2910_diff.txt, derby-2910_stat.txt
>
>
> Following query should run into error if run in a territory based database
> SELECT TABLENAME FROM SYS.SYSTABLES WHERE UPPER(CURRENT_DATE) = TABLENAME;
> When a CAST node is generated on top of CURRENT_DATE to create a character
> string type, we do not set the collation of that character string type and
> hence it always ends up getting the default which is collation derivation
> IMPLICIT and collation type UCS_BASIC. That does not sound right.
> There might be other places where we generate CAST node to create a character
> string type. We should check if the collation is set correctly for them.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
