Accept multiple --execute options and run each specified query in turn

[rolandwalker]

Description

Accept multiple --execute options and run each specified query in turn

The current behavior is to accept multiple --execute options, but to only execute the last one: a bug.

Since there are multiple values, we can also support --throttle, per the discussion in #1460.

One inconsistency between STDIN and --execute is that --execute does not support warning on destructive queries. This should probably be resolved in the direction of removing the warning from scripts on STDIN.

Checklist

• I've added this contribution to the changelog.md.
• I've added my name to the AUTHORS file (or it's already there).
• I ran uv run ruff check && uv run ruff format && uv run mypy --install-types . to lint and format the code.

[scottnemes]

What is the benefit of multiple executes over running multiple queries within a single execute like you would normally?

I.e.

mycli -e "select 1; select 2; select 3"

vs

mycli -e "select 1" -e "select 2" -e "select 3"

Unless there is a specific use case that seems unnecessary. My original comment was around the fact that you could technically have the throttle affect the multiple queries passed at once, since we parse the queries one by one anyway.

[rolandwalker]

The benefits are:

• unify the two batch modes with the same behavior
• fix an untenable bug: only the last --execute was (silently) respected

[scottnemes]

The benefits are:

• unify the two batch modes with the same behavior
• fix an untenable bug: only the last --execute was (silently) respected

Unclear why you need multiple -e params to unify the batch modes? RE: the multiple -e bug, I'd lean towards checking for that scenario and erroring vs adding it in as functionality to avoid the bug. The behavior of accepting multiple is the same for all "basic" options, so we'd be selectively changing that in this case.

mycli -u scottn -u noob
(1045, "Access denied for user 'noob'@'localhost' (using password: NO)")

[github-actions]

Findings

1. Potential regression: --execute no longer strips trailing \G when --batch output is requested, so expanded output can override batch formatting (CSV/TSV/table). Previously \G was ignored in batch mode for --execute; now sqlexecute.run() treats it as vertical output. This can break scripts expecting CSV/TSV even if queries end with \G.
   Files: mycli/main.py (execute loop), mycli/sqlexecute.py (expanded output handling)

2. Behavior change risk: For multiple -e in CSV/TSV, headers are only emitted for the first query (csv-noheader/tsv_noheader for subsequent queries). If users expect each -e to behave independently (i.e., include headers), this is a regression in multi--e mode. If this is intended, it should be documented and tested.
   Files: mycli/main.py (set_batch_formatter)

Missing tests / edge cases

1. Add coverage for --execute with \G in batch formats, to lock in intended behavior (ignore \G vs expanded output).
   File: test/test_main.py

2. Add coverage for multiple -e with --batch CSV/TSV to confirm header/noheader behavior is intentional.
   File: test/test_main.py

Questions / clarifications

1. Do you want \G to be honored or ignored when --batch (CSV/TSV/table) is set for --execute? The previous behavior ignored it; current behavior honors it and may change output format.

If you want, I can propose a minimal patch to restore the old \G-strip behavior for --execute in batch mode and add the tests above.