From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)surnet(dot)cl>, hf1122x(at)protecting(dot)net, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Missing numbers |
Date: | 2005-06-01 15:23:26 |
Message-ID: | 14247.1117639406@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Wed, 2005-06-01 at 00:27 -0400, Alvaro Herrera wrote:
>>> SELECT g.num
>>> FROM generate_series ((SELECT min(doc_numero) FROM bdocs),
>>> (SELECT max(doc_numero) FROM bdocs)) AS g(num)
>>> LEFT JOIN bdocs ON bdocs.doc_numero = g.num
>>> WHERE bdocs.doc_numero IS NULL
> I wonder what the SQL spec should happen in this case? It depends upon
> whether the NOT NULLs are excluded before or after the join takes
> place.
The spec says that WHERE is logically applied after the join. In some
cases it is possible to push the condition down to occur before the join
without changing the results ... but not in the above case.
> Either way, I still prefer my phrasing of the SQL, which seems clearer,
> but I would say that wouldn't I?
Maybe so. The outer-join-and-test-for-null is a pretty common idiom
though, so I'd expect experienced SQL programmers to recognize it on
sight.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gerald D. Anderson | 2005-06-01 15:24:25 | Old problem needs solution |
Previous Message | Jim Buttafuoco | 2005-06-01 15:20:08 | Re: SQL question. |