[
https://issues.apache.org/jira/browse/DERBY-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-6566:
--------------------------------------
Attachment: releaseNote.html
Attaching a release note for this issue.
> 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
> 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)
