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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] don't know whether nodes of type 719 are equal
Date: 1999-10-17 21:47:11
Message-ID: 19154.940196831@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-10-17 22:29:40 Re: [HACKERS] sort on huge table
Previous Message Daniel Péder 1999-10-17 20:56:45 insertable views - not copy-able ?