db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6566) Simplify handling of untyped nulls in CASE and NULLIF expressions
Date Tue, 27 May 2014 18:22:03 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010045#comment-14010045

Mike Matrigali commented on DERBY-6566:

Is there any soft vs hard upgrade issue with this change? 

It looks to me like this is just a runtime change, so a soft upgrader will get new behavior
when running
new software, but if they revert to old software they will get original behavior - right?

> Simplify handling of untyped nulls in CASE and NULLIF expressions
> -----------------------------------------------------------------
>                 Key: DERBY-6566
>                 URL: https://issues.apache.org/jira/browse/DERBY-6566
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>              Labels: derby_backport_reject_10_10
>             Fix For:
>         Attachments: d6566-1a.diff, releaseNote.html
> The parser translates both CASE and NULLIF expressions into ConditionalNodes, but it
represents untyped NULLs differently in the two cases.
> In a CASE expression, any branch that is an untyped NULL, is translated into an UntypedNullConstantNode
that's wrapped in a CastNode that casts the value to CHAR(1). The CastNode is replaced with
a cast to the correct type during the bind phase.
> A NULLIF expression is turned into a CASE expression that has a THEN NULL clause. The
parser simply creates an UntypedNullConstantNode for that clause, without wrapping it in a
CastNode. A CastNode is instead added during the bind phase.
> This slight difference in how NULLs are represented by the parser in the two cases, means
that ConditionalNode needs to handle the two cases differently during the bind phase. It would
be better if the parser generated NULLs in the same way for the two cases, so that ConditionalNode
didn't need to know if it was generated for a CASE expression or a NULLIF expression.

This message was sent by Atlassian JIRA

View raw message