Re: Make transformAExprIn() return a flattened bool expression directly
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: ZizhuanLiu X-MAN <44973863@qq.com>
Cc: cca5507 <cca5507@qq.com>, Chao Li <li.evan.chao@gmail.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-07-01T22:21:15Z
Lists: pgsql-hackers
"=?utf-8?B?Wml6aHVhbkxpdSBYLU1BTg==?=" <44973863@qq.com> writes: > Thanks a lot for the suggestion to avoid nested structures in transformAExprIn(). > I also agree that handling this kind of simplification during parsing is cleaner and more appropriate, > even though the planner can achieve a similar effect later via preprocess_qual_conditions(). Just for the record, I think this is a bad idea that we should reject. In general, it is not the business of the parser to perform optimizations. Where we have done that, we've often regretted it. In the specific case at hand, doing this is presupposing that all parse- and rewrite-time logic is capable of dealing with non-binary AND and OR nodes. That seems like a significant risk to me. At the very least it seems likely to lead to unexpected changes in view dump output. In exchange for taking that nonzero risk, what are we buying? You've offered no evidence of a meaningful or even measurable improvement. regards, tom lane