Comments on: Where is my WHERE?

By: Steve Pratt

Steve Pratt — Tue, 01 Jul 2008 15:21:06 +0000

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

Alex Nuijten — Sun, 23 Dec 2007 09:31:03 +0000

Thank you for the link, Rob. Very enlightening….

By: Borkur Steingrimsson

Borkur Steingrimsson — Fri, 21 Dec 2007 14:51:09 +0000

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

Rob van Wijk — Fri, 21 Dec 2007 11:17:55 +0000

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

Alex Nuijten — Fri, 21 Dec 2007 10:36:18 +0000

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

Niall Litchfield — Fri, 21 Dec 2007 10:32:03 +0000

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

Niall Litchfield — Fri, 21 Dec 2007 10:31:06 +0000

The comment out issue is one reason why I use the writing style

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

Borkur Steingrimsson — Fri, 21 Dec 2007 10:10:40 +0000

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

Dominic Brooks — Fri, 21 Dec 2007 10:05:58 +0000

‘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

Marco Gralike — Fri, 21 Dec 2007 09:50:27 +0000

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