Re: [HACKERS] don't know whether nodes of type 719 are equal
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] don't know whether nodes of type 719 are equal |
Дата | |
Msg-id | 22180.940223456@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] don't know whether nodes of type 719 are equal (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: