-----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-----
|