Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> I also got this message with UNION and distinct.
>> I've tested 6.5.2 and 6.5.3. Current (6.6 or 7.0 ?) works fine
> Me too. Current works fine, but 6.5.2 not.
No, it's still there in current:
regression=> explain select distinct * from tenk1
regression-> union select distinct * from tenk1;
NOTICE: equal: don't know whether nodes of type 719 are equal
NOTICE: QUERY PLAN:
... etc ...
It might be a little harder to get in current. I think that in
a fit of code beautification I rearranged _equalQuery so that the
sort/group clauses are tested later than they used to be. You
won't see this notice if _equalQuery discovers that the query
nodes are non-identical before it gets to the sort specification.
Thus:
regression=> explain select distinct * from tenk1 t1
regression-> union select distinct * from tenk1 t2;
NOTICE: QUERY PLAN:
... etc ...
This entirely equivalent query has different refnames in the rangetables
of the two subselects, which means equal() considers the nodes
non-identical; and the rangetable is checked by equalQuery before it
gets to the sort clause. So the sort clauses are never compared.
Bingo, no message.
Being harder to get doesn't make it any less a bug, of course.
But I'm not especially concerned about it --- the query works,
the message is just noise; so I think we can live with it until
we get around to doing the major querytree redesign that we need
to do for subselects in FROM as well as some less pressing problems
like this one...
regards, tom lane
