On Sun, Nov 27, 2016 at 10:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I think you made this considerably more fragile with those changes. > > This code will only ever run at all in corner cases --- cases that > almost by definition will go untested in the standard regression tests. > The problems you suggest it has are corner-squared or corner-cubed cases. > We were rather fortunate to find the bugs in the committed version before > it got into the field, and would be even less likely to find bugs in code > that is meant to run in corner-squared cases. So, with all due respect, > I think your priorities here are entirely backwards.
I am of the contrary opinion - I think *your* priorities are backwards. Describing those as corner-squared or corner-cubed cases is misleading; it is true that they will arise for very few users, but they may be catastrophic when they do arise. On the other hand, the logic you've removed might have been bug-free (in which case removing it is strictly a loss) or it might have had only bugs without any particularly serious consequences (in which case you've traded little problems for big ones). Even if it does have a serious bug, there's no reason to suppose it will be impossible to find; why shouldn't the BF or beta testing or dev testing reveal it, just as it revealed this bug? I don't believe we should be so scared of the possibility of a serious bug that can't be found through any of the ways we normally test that we aren't willing to fix problems we can readily foresee. I grant that there are some situations where fixing a problem might involve enough risk that we shouldn't attempt it, but this is (or was) pretty straightforward code patterned after existing logic, and I really see no reason to believe that anything that was wrong with it couldn't have been debugged easily enough. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers