On Thu, Jul 18, 2013 at 10:19 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > > Because simpler code is less likely to have bugs and is easier to > > maintain. > > I agree with that point, but one should also remember Polya's Inventor's > Paradox: the more general problem may be easier to solve. That is, if > done right, code that fully flattens an AND tree might actually be > simpler than code that does just a subset of the transformation. The > current patch fails to meet this expectation, The current patch does completely flatten any type of tree (left/right-deep or bushy) without recursing, and right-deep and bushy tree processing is what Robert is recommending to defer to recursive processing. Maybe I haven't considered a case where it doesn't flatten the tree; do you have an example in mind. > but maybe you just haven't > thought about it the right way. > > My concerns about this patch have little to do with that, though, and > much more to do with the likelihood that it breaks some other piece of > code that is expecting AND/OR to be strictly binary operators, which > is what they've always been in parsetrees that haven't reached the > planner. It doesn't appear to me that you've done any research on that > point whatsoever No, I haven't, and I might not be able to research it for a few more weeks. > you have not even updated the comment for BoolExpr > (in primnodes.h) that this patch falsifies. > I will fix that. Best regards, -- Gurjeet Singh http://gurjeet.singh.im/ EnterpriseDB Inc.