https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6454
--- Comment #4 from Kevin A. McGrail <[email protected]> 2010-06-16 13:01:51 EDT --- (In reply to comment #3) > (In reply to comment #2) > > I'm not voting on this issue but worried the patch could have unanticipated > > consequences. > > DBI can return 0E0 "If no rows were affected, then "execute" returns "0E0", > > which Perl will treat as 0 but will regard as true." > > 0E0 will eval to true because it's a string. > > I am concerned when I saw you remove the check on '0E0' as being a possible > > problem and wondered if you new about this silly return code issue and why > > it > > is/isn't an issue here. > > I think you misunderstood the issue. The calls to ->do and ->execute > do behave as you describe, and according to their documentation. > > Unlike a call to ->rows, which does NOT behave this way, > nor in the docs, nor in reality. I have only changed a test > on return value from ->rows. Other calls to do and execute > are untouched, they still test for '0E0'. > > This only affects the PgSQL module. The MySQL module does not call > the rows method, but uses a return value from ->do, which is why > a test for '0E0' there is still appropriate and correct there. Understood. Then it looks good and I see what you mean that the test for 0e0 was a complete error previously. +1 -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
