Comments on: Where is my WHERE? https://technology.amis.nl/2007/12/21/where-is-my-where/ Friends of Oracle and Java Wed, 24 Jun 2015 09:59:44 +0000 hourly 1 http://wordpress.org/?v=4.2.2 By: Steve Pratt https://technology.amis.nl/2007/12/21/where-is-my-where/#comment-5095 Tue, 01 Jul 2008 15:21:06 +0000 http://technology.amis.nl/blog/?p=2673#comment-5095 Back in the ‘old’ days of RDBMSes, sometimes it was necessary to fool the optimizer in order to force a specific access path. And one technique was to include an absolute truth in the WHERE clause. (this was obviously before the advent of optimizer HINTS.)

]]>
By: Alex Nuijten https://technology.amis.nl/2007/12/21/where-is-my-where/#comment-5094 Sun, 23 Dec 2007 09:31:03 +0000 http://technology.amis.nl/blog/?p=2673#comment-5094 Thank you for the link, Rob. Very enlightening….

]]>
By: Borkur Steingrimsson https://technology.amis.nl/2007/12/21/where-is-my-where/#comment-5093 Fri, 21 Dec 2007 14:51:09 +0000 http://technology.amis.nl/blog/?p=2673#comment-5093 well, the error you get

ERROR at line 15:
ORA-25154: column part of USING clause cannot have qualifier

is exactly that. You can not put anywhere in your statement things like “t.id =3″ (in the SELECT or the WHERE clause) as the error message suggests. Instead you would have to put just “id = 3″, without the table alias (qualifier). This also applies to doing something like ” SELECT S.* from …” and then ANSI JOIN with the USING keyword. It would result in the same error being raised. If you alter your example to reflect this, you will then see that the USING part does not extend outside of the parentheses and the WHERE keyword must follow before you put other predicates.

]]>
By: Rob van Wijk https://technology.amis.nl/2007/12/21/where-is-my-where/#comment-5092 Fri, 21 Dec 2007 11:17:55 +0000 http://technology.amis.nl/blog/?p=2673#comment-5092 Alex,

As said, you converted a predicate to a join condition. This can be done safely for inner joins, i.e. it doesn’t affect the result of your query, but if you do the same for an outer join the result set may change. See this article from Jonathan Gennick about this behaviour: http://www.oreillynet.com/pub/a/network/2002/10/01/whatsinacondition.html

Regards,
Rob.

]]>
By: Alex Nuijten https://technology.amis.nl/2007/12/21/where-is-my-where/#comment-5091 Fri, 21 Dec 2007 10:36:18 +0000 http://technology.amis.nl/blog/?p=2673#comment-5091 Thank you all for your comments. I took the liberty to place them into the main section of the post, as the layout in the comments section is less than ideal. :)

]]>
By: Niall Litchfield https://technology.amis.nl/2007/12/21/where-is-my-where/#comment-5090 Fri, 21 Dec 2007 10:32:03 +0000 http://technology.amis.nl/blog/?p=2673#comment-5090 OK lets see if the pre tag is accepted so you can see what I mean

SELECT
first_col
, second_col


, last_col
FROM
first_tab join second_tab
on (join clause)
WHERE
first_condition
and second_condition
and …
GROUP BY
first groupby
, second groupby

HAVING
first having
, second having

ORDER BY
first_col
, second_col

]]>
By: Niall Litchfield https://technology.amis.nl/2007/12/21/where-is-my-where/#comment-5089 Fri, 21 Dec 2007 10:31:06 +0000 http://technology.amis.nl/blog/?p=2673#comment-5089 The comment out issue is one reason why I use the writing style

SELECT
first_col
, second_col


, last_col
FROM
first_tab join second_tab
on (join clause)
WHERE
first_condition
and second_condition
and …
GROUP BY
first groupby
, second groupby

HAVING
first having
, second having

ORDER BY
first_col
, second_col

i.e KEYWORDS on their own, start lines with a , (if appropriate) I also find it more readable.

Incidentally many sql generators – programs that generate sql based on forms etc – will start the where with 1=1 so they don’t have to work out which is the first condition.

]]>
By: Borkur Steingrimsson https://technology.amis.nl/2007/12/21/where-is-my-where/#comment-5088 Fri, 21 Dec 2007 10:10:40 +0000 http://technology.amis.nl/blog/?p=2673#comment-5088 Well, this is for sure not a bug. This is really normal and expected behavior. The ON clause extends to line 7 in your last example, since you don’t have to use parenthesis. If you had written something like

SQL> select
2 *
3 from t
4 join s
5 USING (id) –Notice the difference here
6 —- where t.id = 3
7 and s.id = 3
8 /

Then your query would fail.

Regarding leaving a “1=1″ in production could, whilst not being very clean or pretty, I would not find it likely to cause a lot overhead :) I wonder how many queries per second you would need to be able to measure the effect of it ..

]]>
By: Dominic Brooks https://technology.amis.nl/2007/12/21/where-is-my-where/#comment-5087 Fri, 21 Dec 2007 10:05:58 +0000 http://technology.amis.nl/blog/?p=2673#comment-5087 ‘where 1=1′ is often also used by code that dynamically generates queries depending on inputs, presumably so it doesn’t need to figure out whether a dynamically generated predicate should use ‘where’ or ‘and’.

]]>
By: Marco Gralike https://technology.amis.nl/2007/12/21/where-is-my-where/#comment-5086 Fri, 21 Dec 2007 09:50:27 +0000 http://technology.amis.nl/blog/?p=2673#comment-5086 Ehhh… “where 1=1″, if it remains in the production code, isn’t it also a performance degradation issue (doing an unneeded check that costs at least CPU time?)

]]>