[shaurya703]

Description

is_destructive() stops at the first single-table UPDATE ... WHERE and returns False, so the statements after it are never checked. Running

UPDATE t SET x = 1 WHERE id = 1; DROP DATABASE prod;

at the prompt (or with --execute/batch mode and --warn-batch) runs the DROP DATABASE without the destructive-warning confirmation. The same happens for UPDATE ... WHERE ...; UPDATE t SET x = 2;, where the second update has no WHERE.

The fix replaces the early return False with continue, so a safe UPDATE is skipped and the loop keeps checking the rest of the input. The function still returns False only when no statement matches.

Added two tests in test_sql_utils.py (safe UPDATE followed by DROP DATABASE, and safe UPDATE followed by an UPDATE without WHERE). Both fail on main and pass with this change; the rest of test_sql_utils.py still passes.

Checklist

• I added this contribution to the changelog.md file.
• I added my name to the mycli/AUTHORS.txt file (or it's already there).
• To lint and format the code, I ran

  uv run ruff check && uv run ruff format && uv run mypy --install-types .

[rolandwalker]

Much appreciated!

[rolandwalker]

Going out now in release https://github.com/dbcli/mycli/releases/tag/v2.30.2 .