Understanding T-SQL Expression Short-Circuiting

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Gianluca Sartori » Understanding T-SQL Expression...

54 posts, Page 6 of 6

«««2 3 4 5 6

Understanding T-SQL Expression Short-Circuiting

Rate Topic

Display Mode

Topic Options

Author

Message

spaghettidba

Posted Monday, March 07, 2011 10:30 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: 2 days ago @ 8:29 AM
Points: 4,804, Visits: 8,067

Thanks for clarifying, Bart.
I filed a Connect item here:
https://connect.microsoft.com/SQLServer/feedback/details/649957/case-expression-evaluates-else-branch-at-compile-time.

Let's see what happens.

Get your two-cent-answer quickly
The Spaghetti DBA

Post #1074310

Bart Duncan

Posted Monday, March 21, 2011 7:44 PM

Forum Newbie

Group: General Forum Members
Last Login: Wednesday, April 06, 2011 12:49 PM
Points: 6, Visits: 20

Update to anyone following this: this compile-time exception to normal T-SQL CASE short circuiting is now scheduled to be fixed in an upcoming SQL release, thanks to Gianluca for filing the Connect bug. For now the problem behavior still exists in SQL2005 through SQL2008R2 -- and maybe SQL2000 -- so keep an eye out for it in existing releases as you use CASE for short-circuiting.

Post #1081706

spaghettidba

Posted Tuesday, March 22, 2011 1:30 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: 2 days ago @ 8:29 AM
Points: 4,804, Visits: 8,067

Thanks for the feedback, Bart.
It's nice to see a problem fixed in such a short time.

Get your two-cent-answer quickly
The Spaghetti DBA

Post #1081768

Arto Ahlstedt

Posted Saturday, October 22, 2011 4:59 PM

SSC Veteran

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 2:13 AM
Points: 298, Visits: 574

Nice article and nice work on the floating-point exception bug.

Now, to give this dead horse the final whiplash, I was intrigued by the IN handling and modified the set (30,20,10,1) into (30,20,30,10,1). Sure enough, the IN expression was optimized down to 4 ordered OR subexpressions in the query plan like before. Distinct sort seems to be the easiest way to expand only distinct values in the set into OR expressions. It just happens to also sort the values as a benign side-effect.

Post #1194896

« Prev Topic | Next Topic »

54 posts, Page 6 of 6

«««2 3 4 5 6

Permissions