Peter Eisentraut <peter_e@gmx.net> writes:
> SELECT DISTINCT t.typname as "Name" FROM pg_type t
> UNION ALL
> SELECT DISTINCT c.relname as "Name" FROM pg_class c
> ;
> (It doesn't make much sense as it stands, but I have picked out the
> offending parts.)
> I get
> NOTICE: equal: don't know whether nodes of type 719 are equal
(consults include/nodes/nodes.h ... hmm, "SortClause" ...)
This is probably happening because UNION/INTERSECT processing tries
to simplify the node tree using cnfify(), which is really designed
to work on expressions not whole queries. Ordinarily you can't get a
sort clause into a subclause of a UNION ... but I guess with DISTINCT
you can. (I bet UNIONing things containing GROUP BY fails too,
since equal() doesn't know about GroupClause nodes either.)
A quick-fix answer is to extend equal(), of course, but I've been
wondering for a while why we are cnfify'ing UNION/INTERSECT trees
at all. The odds of being able to simplify the tree that way seem
small, and what's worse is that UNION does *not* have the same
semantics as OR (eg, foo UNION foo should *not* be simplified to foo)
but cnfify doesn't know that.
regards, tom lane
