| 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: | Whole Thread | Raw Message | 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 ? |