From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Edward Q(dot) Bridges" <ed(dot)bridges(at)buzznik(dot)com> |
Cc: | "pgsql-general" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Is this proper UNION behavior?? |
Date: | 2000-11-14 03:12:39 |
Message-ID: | 25590.974171559@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Edward Q. Bridges" <ed(dot)bridges(at)buzznik(dot)com> writes:
> ebridges=> (select * from has_some_dupes)
> ebridges-> UNION
> ebridges-> (select * from has_some_dupes);
[ produces the same result as "select * from has_some_dupes" ]
Yup, that's a bug in 7.0.* (and a version or two before). There's
a planning step that thinks it can simplify UNION/INTERSECT/EXCEPT
expressions as if they were boolean expressions --- in particular,
since "X or X = X", it thinks "X union X = X". Unfortunately,
whoever wrote that code hadn't actually bothered to consult the
SQL spec about the semantics of UNION, INTERSECT, or EXCEPT :-(.
The spec's rules about duplicate elimination mean that the behavior
is NOT quite like boolean OR/AND/AND NOT.
Since people don't ordinarily write queries as silly as X union X,
this bug hasn't been very high priority to fix. But it is fixed
for 7.1 ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ned Lilly | 2000-11-14 03:27:10 | GT.M database open sourced |
Previous Message | Tom Lane | 2000-11-14 03:04:11 | Re: Problems during doing reindex on 7.0.3 |