-----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/[EMAIL PROTECTED]&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-----
