"=?utf-8?B?Wml6aHVhbkxpdSBYLU1BTg==?=" <[email protected]> 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
