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
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 ? |