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
