Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 28 May 2014 09:59:02 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12713029.1399534289110.30556.1401271142001@arcas>
In-Reply-To: <JIRA.12713029.1399534289110@arcas>
References: <JIRA.12713029.1399534289110@arcas>
Subject: [jira] [Commented] (DERBY-6566) Simplify handling of untyped nulls
 in CASE and NULLIF expressions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Knut Anders Hatlen commented on DERBY-6566:
-------------------------------------------

That's correct. This change only streamlines how ConditionalNode.bindExpression() infers the type of an untyped NULL. It's just a compiler change. No change to the stored format.

The possible compatibility issue is that the new logic does not attempt to infer the type of an already typed NULL. So if you for example say WHEN a=b THEN CAST(NULL AS BLOB), and the context requires the result to be an INTEGER, we now raise a type-mismatch error instead of silently rewriting CAST(NULL AS BLOB) to CAST(NULL AS INTEGER). If you soft downgrade to an earlier version, you'll get the old behaviour again.

I agree that this change should not be backported.

> 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: 11.0.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>              Labels: derby_backport_reject_10_10
>             Fix For: 10.11.0.0
>
>         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
(v6.2#6252)