Auto-commit vs. explicit transactions: retry safety for SQL writes in PyCharm's Database console

In current PyCharm releases, retrying a SQL statement in the Database console after a transient error forces a choice between auto-commit and an explicit transaction, and that choice determines whether a retry can duplicate a write. With auto-commit enabled, each statement is committed immediately, so re-executing an INSERT after a failure can create a second row unless the statement is idempotent or guards against existing data. Disabling auto-commit allows the statement to run inside an explicit transaction that can be rolled back and retried as a unit, but the console does not persistently warn if the transaction is left open or uncommitted after a failed attempt, which can leave the session in an indeterminate state.

The trade-off is further complicated by the fact that changing the auto-commit setting requires reconnecting the data source, making it a per-session decision rather than a quick toggle. For ad hoc INSERT retries, does disabling auto-commit and managing explicit transactions provide a safer default than relying on idempotent statements under auto-commit? How should one weigh the risk of forgotten commits or rollbacks in manual transaction mode against the duplicate-write risk of auto-commit when reconnecting the data source is costly? Is there a documented PyCharm workflow that reconciles these two modes without requiring a mid-session reconnect?