<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Eddie Awad’s Blog - Latest Comments in The order of conditions matters</title><link>http://awads.disqus.com/</link><description>News, views, tips and tricks on Oracle and other fun stuff</description><atom:link href="https://awads.disqus.com/the_order_of_conditions_matters/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Wed, 30 Jul 2008 11:23:16 -0000</lastBuildDate><item><title>Re: The order of conditions matters</title><link>http://awads.net/wp/2006/03/03/the-order-of-conditions-matters/#comment-3658377</link><description>&lt;p&gt;Quote iG "It is NOT ALWAYS guaranted..." then iG goes on to show  an example in SQL.&lt;br&gt;But remember that the order of evaluation in SQL is not as written.&lt;br&gt;&lt;/p&gt;&lt;pre&gt;SQL&amp;gt; CREATE OR REPLACE FUNCTION this_is_y(x NUMBER) RETURN VARCHAR2 IS&lt;br&gt;  2  BEGIN&lt;br&gt;  3    dbms_output.put_line('Inside function this_is_Y(' || x || ')');&lt;br&gt;  4    RETURN 'Y';&lt;br&gt;  5  END this_is_Y;&lt;br&gt;  6  /&lt;br&gt;&lt;br&gt;Function created.&lt;br&gt;&lt;br&gt;SQL&amp;gt; CREATE OR REPLACE FUNCTION this_is_n(x NUMBER) RETURN VARCHAR2 IS&lt;br&gt;  2  BEGIN&lt;br&gt;  3    dbms_output.put_line('Inside function this_is_N(' || x || ')');&lt;br&gt;  4    RETURN 'N';&lt;br&gt;  5  END this_is_n;&lt;br&gt;  6  /&lt;br&gt;&lt;br&gt;Function created.&lt;br&gt;&lt;/pre&gt;&lt;p&gt;&lt;br&gt;&lt;/p&gt;&lt;pre&gt;SQL&amp;gt; SELECT *&lt;br&gt;  2  FROM   (SELECT object_id&lt;br&gt;  3          FROM   user_objects&lt;br&gt;  4          WHERE  9 &amp;gt; rownum)&lt;br&gt;  5  WHERE  this_is_y(object_id) = 'Y'&lt;br&gt;  6  AND    this_is_n(object_id) = 'Y';&lt;br&gt;&lt;br&gt;no rows selected&lt;br&gt;&lt;br&gt;SQL&amp;gt;&lt;br&gt;&lt;/pre&gt;&lt;p&gt;&lt;br&gt;And the output is:&lt;br&gt;&lt;/p&gt;&lt;pre&gt;Inside function this_is_N(174702)&lt;br&gt;Inside function this_is_N(592838)&lt;br&gt;Inside function this_is_N(592839)&lt;br&gt;Inside function this_is_N(592840)&lt;br&gt;Inside function this_is_N(592841)&lt;br&gt;Inside function this_is_N(592842)&lt;br&gt;Inside function this_is_N(592843)&lt;br&gt;Inside function this_is_N(592844)&lt;br&gt;&lt;/pre&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Steven Meyer</dc:creator><pubDate>Wed, 30 Jul 2008 11:23:16 -0000</pubDate></item><item><title>Re: The order of conditions matters</title><link>http://awads.net/wp/2006/03/03/the-order-of-conditions-matters/#comment-3658376</link><description>&lt;p&gt;Its NOT ALWAYS guaranted the in&lt;/p&gt;&lt;p&gt;&lt;br&gt;&lt;/p&gt;&lt;p&gt;select from my_table where cond1 and cond2;&lt;/p&gt;&lt;p&gt;&lt;br&gt;&lt;/p&gt;&lt;p&gt;cond1 be first evaluated. For a query I was doing, a must use:&lt;/p&gt;&lt;p&gt;&lt;br&gt;&lt;/p&gt;&lt;p&gt;select /*+ no_cpu_costing */ from my_table where cond1 and cond2;&lt;/p&gt;&lt;p&gt;&lt;br&gt;&lt;/p&gt;&lt;p&gt;Look at&lt;/p&gt;&lt;p&gt;&lt;br&gt;&lt;/p&gt;&lt;p&gt;&lt;a href="http://www.dba-oracle.com/oracle_tips_optimizer_cost_model.htm" rel="nofollow noopener" target="_blank" title="http://www.dba-oracle.com/oracle_tips_optimizer_cost_model.htm"&gt;http://www.dba-oracle.com/o...&lt;/a&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">iG</dc:creator><pubDate>Sat, 11 Aug 2007 10:04:51 -0000</pubDate></item><item><title>Re: The order of conditions matters</title><link>http://awads.net/wp/2006/03/03/the-order-of-conditions-matters/#comment-3658375</link><description>&lt;p&gt;If (and only if) this behaviour is a standard&lt;br&gt;in PLSQL, then one could argue that the&lt;br&gt;more concise code that can be written &lt;br&gt;using this IS more maintainable. More&lt;br&gt;verbose code, especially if it requires the&lt;br&gt;setting up and initialisation of more &lt;br&gt;unnecessary variables, can reduce the maintainability of that code!&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gaza</dc:creator><pubDate>Thu, 26 Jul 2007 00:32:38 -0000</pubDate></item><item><title>Re: The order of conditions matters</title><link>http://awads.net/wp/2006/03/03/the-order-of-conditions-matters/#comment-3658373</link><description>&lt;p&gt;Good and valid points Rob. Thank you. Nevertheless, the short-circuit evaluation notion in PL/SQL is rather an interesting fact (as of 10gR2).&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Eddie Awad</dc:creator><pubDate>Fri, 03 Mar 2006 14:51:02 -0000</pubDate></item><item><title>Re: The order of conditions matters</title><link>http://awads.net/wp/2006/03/03/the-order-of-conditions-matters/#comment-3658374</link><description>&lt;p&gt;Interesting.  But is this behaviour dependable?  And, if so, will it remain like this in future versions?  And, even if it is, is that necessarily the best coding practise?  Especially since you can just do this:&lt;/p&gt;&lt;p&gt;&lt;br&gt;&lt;/p&gt;&lt;p&gt;IF (2=1) THEN&lt;br&gt;     IF (IS_GREATER_FUNC(1,2)) THEN&lt;br&gt;          DBMS_OUTPUT.PUT_LINE('TRUE');&lt;br&gt;     ELSE DBMS_OUTPUT.PUT_LINE('FALSE');&lt;br&gt;     END IF;&lt;br&gt;ELSE DBMS_OUTPUT.PUT_LINE('FALSE');&lt;br&gt;END IF;&lt;/p&gt;&lt;p&gt;&lt;br&gt;&lt;/p&gt;&lt;p&gt;That way, your intention (to only check the second case if the first case is true) is clear, and dependable.  Sure, it's more lines of code, but easier to maintain.&lt;/p&gt;&lt;p&gt;&lt;br&gt;&lt;/p&gt;&lt;p&gt;Rob&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Robert Vollman</dc:creator><pubDate>Fri, 03 Mar 2006 13:19:21 -0000</pubDate></item></channel></rss>