https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6454
--- Comment #3 from Mark Martinec <[email protected]> 2010-06-16 12:55:05 EDT --- (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. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
