Re: [HACKERS] equal: don't know whether nodes of type 600 are equal

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] equal: don't know whether nodes of type 600 are equal
Дата
Msg-id 24423.918350020@sss.pgh.pa.us
обсуждение исходный текст
Ответ на equal: don't know whether nodes of type 600 are equal  (Vadim Mikheev <vadim@krs.ru>)
Ответы Re: [HACKERS] equal: don't know whether nodes of type 600 are equal  (jwieck@debis.com (Jan Wieck))
Список pgsql-hackers
I chased down the complaints that were coming out of the union regress
test:

> regression=> SELECT 1 AS two UNION SELECT 2;
> NOTICE:  equal: don't know whether nodes of type 600 are equal

and found that this was a known shortcoming of the recently installed
EXCEPT/INTERSECT code:

>> -) When using UNION/EXCEPT/INTERSECT you will get:
>>    NOTICE: equal: "Don't know if nodes of type xxx are equal".
>>    I did not have  time to add comparsion support for all the needed nodes,
>>    but the default behaviour of the function equal met my requirements.
>>    I did not dare to supress this message!
>> 
>>    That's the reason why the regression test for union will fail: These
>>    messages are also included in the union.out file!

I added equality checking for T_Query and T_RangeTblEntry to
equalfuncs.c.  This is enough to persuade the regression tests
to pass again, but I suspect that some other node types still
need to be added to equal()'s repertoire.

We are definitely not out of the woods with the EXCEPT/INTERSECT changes:

test=> EXPLAIN SELECT 1 UNION SELECT 2;
ERROR:  copyObject: don't know how to copy 604

I do not think that extending copyObject to handle 604 (T_SelectStmt)
is necessarily the right fix here.  I am casting a wary eye on
the first lines of ExplainOneQuery:
/* plan the queries (XXX we've ignored rewrite!!) */plan = planner(query);

I think the real problem is that the EXCEPT/INTERSECT code is dependent
on rewrite work that is not being done in the EXPLAIN path, and that
we need to fix that underlying problem rather than patching the symptom.
Otherwise we'll likely just hit another symptom...

I'm about out of steam for today so I'll just toss that up to see if
anyone else wants to tackle it.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Re: SELECT INTO TABLE busted?
Следующее
От: The Hermit Hacker
Дата:
Сообщение: One I've never seen before: