From: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Oops, I seem to have changed UNION's behavior |
Date: | 1999-02-08 16:33:52 |
Message-ID: | 36BF11F0.24955447@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> The equal() updates I installed yesterday (to fix the "don't know
> whether nodes of type 600 are equal" problem) have had an unintended
> side effect.
> Am I right in thinking that UNION (without ALL) is defined to do a
> DISTINCT on its result, so that duplicates are removed even if the
> duplicates both came from the same source table? That's what 6.4.2
> does, but I do not know if it's strictly kosher according to the SQL
> spec.
Yup, that's the way it should be...
> If so, the code is now busted, because with the equal() extension in
> place, cnfify() is able to recognize and remove duplicate select
> clauses. That is, "SELECT xxx UNION SELECT xxx" will be folded to
> just "SELECT xxx" ... and that doesn't mean the same thing.
:(
> Assuming that 6.4.2 is doing the Right Thing, I see two possible
> fixes:
> (1) simplify equal() to say that two T_Query nodes are never equal, or
> (2) modify the planner so that the "select distinct" operation is
> inserted explicitly, and will thus happen even if the UNIONed selects
> are collapsed into just one.
Sounds to me like (2) is the correct way to do it, as long as the
explicit "sort/unique" happens only if the query is collapsed. I haven't
looked at this code, and have no experience with cnfify(), but at the
time it decides to collapse into a single select, can't it ensure that a
sort/unique is done instead? Or is that what you are suggesting?
Wouldn't want to have two sort/unique operations on top of each other...
- Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-02-08 16:34:20 | Re: [HACKERS] trouble with rules |
Previous Message | Jan Wieck | 1999-02-08 16:31:09 | Re: [HACKERS] trouble with rules |