Re: review: Non-recursive processing of AND/OR lists - Mailing list pgsql-hackers

From Gurjeet Singh
Subject Re: review: Non-recursive processing of AND/OR lists
Date
Msg-id CABwTF4Whhh4Mn3vxR+_3oNwfcc_0EHJJR0hSbKwCProLEn6bwA@mail.gmail.com
Whole thread Raw
In response to Re: review: Non-recursive processing of AND/OR lists  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: review: Non-recursive processing of AND/OR lists
List pgsql-hackers
On Thu, Jul 18, 2013 at 10:19 AM, Tom Lane <tgl@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.

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Next
From: Tom Lane
Date:
Subject: Re: is a special cost for external sort?