db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Updated: (DERBY-7) Bug in NULLIF Function
Date Tue, 11 Jan 2005 05:47:58 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Amit Handa (JIRA) wrote:

>  > The conclusion is that the expression
>  >  CASE WHEN ... THEN intValue ELSE charValue END
>  > is non-conforming SQL and may be processed in an
implementation-dependent manner.
>
> I hope this clears your doubts.

Not mine, just because it can be implemented in a non-standard manner,
doesn't mean it's a good idea to do so. At least we would have to define
rules about what the type of such an expression is. I don't see the
benefit from such a change, when in reality I believe there is a real
bug that is somewhat simple to fix.

> Going by comments on this bug, there are two people
> who have voted for the patch.
>
> Please let me know if this patch can be accepted,
> or else let's work out for a better solution.

Did you see my reply ?

http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=derby-dev@db.apache.org&msgNo=1619

I'm basically saying that today we seem to compile the NULLIF(l, r) as

CASE l = r THEN CAST (NULL AS CHAR) ELSE l

I think the cast to CHAR is the problem, hence the CHAR in the error
message for this bug. I think the correct compile is more

CASE l = r THEN <untyped null> ELSE l

and the type of <untyped null> is set to the type of l at bind time.

I don't know about others but today I've only been receiving a small
number of posts from the list, I've had to read from the archives to see
the full discussions.

Dan.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFB42iOIv0S4qsbfuQRAu6VAJ4ztbFEPYqmGjhWJgoDImsG1j4e+gCggSV9
akqirdl7gpW7X19KMrwr9CI=
=FTz8
-----END PGP SIGNATURE-----


Mime
View raw message