From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] don't know whether nodes of type 719 are equal |
Date: | 1999-10-18 04:16:12 |
Message-ID: | 21990.940220172@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> My recollection is that cnfify is not called to simplify, but was
> required at one point so you got the right output. That may no longer
> be the case, but I know it was at some point.
For ordinary qual expressions, the only thing cnfify does that is
actually *necessary* for downstream processing is that it changes
the top-level boolean condition into an implicitly-ANDed list of
clauses. That is, (AND A B ...) becomes (A B ...), anything else
becomes a singleton list ((X)). So you could replace cnfify with
make_ands_implicit() and things would still work. (I believe
Peter Andrews is presently getting useful work done with cnfify
lobotomized in more or less that fashion --- he's using queries
that expand unpleasantly with normal cnfify.)
I am not sure whether this is true for UNION/INTERSECT processing
though. There are some really ugly kluges in UNION/INTERSECT, and
I don't think I understand all of its dependencies.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-10-18 04:25:19 | Re: [HACKERS] don't know whether nodes of type 719 are equal |
Previous Message | Bruce Momjian | 1999-10-18 02:03:36 | Re: [HACKERS] don't know whether nodes of type 719 are equal |