Skip to content

Add support for -y/--yes flag to bypass confirmation prompts#1544

Open
DiegoDAF wants to merge 5 commits into
dbcli:mainfrom
DiegoDAF:feature/yes-option
Open

Add support for -y/--yes flag to bypass confirmation prompts#1544
DiegoDAF wants to merge 5 commits into
dbcli:mainfrom
DiegoDAF:feature/yes-option

Conversation

@DiegoDAF

@DiegoDAF DiegoDAF commented Dec 5, 2025

Copy link
Copy Markdown
Contributor

Summary

This PR adds support for the -y/--yes option to pgcli, allowing users to bypass destructive command confirmation prompts. This is particularly useful for automated scripts and CI/CD pipelines.

Features

  • Skip confirmations: pgcli -y or pgcli --yes
  • Automated-friendly: Perfect for scripts and CI/CD pipelines
  • Safe by default: Flag must be explicitly set
  • Respects transactions: Transaction requirements still apply even with -y
  • Clean output: Suppresses "Your call!" message when auto-confirming

Use Cases

# CI/CD pipeline
pgcli -y -c "DROP TABLE old_data;"

# Automated maintenance script
pgcli --yes -f cleanup.sql

# Interactive use (still requires confirmation)
pgcli  # without -y, prompts as usual

Implementation Details

  • Added force_destructive parameter to PGCli class
  • Modified destructive command checks in two locations:
    • execute_command() method for programmatic execution
    • Interactive command handler in run_cli()
  • When -y is set, confirm_destructive_query() is bypassed
  • Transaction requirements are NOT bypassed (safety measure)
  • "Your call!" message is suppressed when using -y (no user interaction occurred)

Testing

Comprehensive unit tests included:

  • Initialization with different flag values
  • Confirmation bypass when flag is True
  • Normal confirmation flow when flag is False/not set
  • Mock verification that confirmation is/isn't called as expected

Safety Considerations

  • Default behavior unchanged (confirmations still required)
  • Transaction requirements remain enforced
  • Users must explicitly opt-in to skip confirmations
  • Helps prevent accidental destructive operations in interactive use

Made with ❤️ and 🤖 Claude Code

DiegoDAF and others added 2 commits December 5, 2025 15:47
This commit adds support for the -y/--yes option to pgcli, allowing users
to bypass destructive command confirmation prompts. This is particularly
useful for automated scripts and CI/CD pipelines.

Features:
- Single flag to skip all destructive confirmations: pgcli -y
- Long form: pgcli --yes
- Useful for automated environments
- Maintains safety by default (flag must be explicitly set)
- Does not override transaction requirements

When the flag is set:
- Destructive commands execute without prompting
- Transaction requirements still apply
- Error handling remains the same

Comprehensive unit tests included to verify:
- Flag initialization
- Confirmation bypass behavior
- Normal confirmation flow without flag

Made with ❤️ and 🤖 Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>
When using the --yes flag to auto-confirm destructive commands,
pgcli should not display the "Your call!" message since no user
interaction occurred. This message is now only shown when the user
manually confirms the destructive warning prompt.

Made with ❤️ and 🤖 Claude Code

Co-Authored-By: Claude <noreply@anthropic.com>
@DiegoDAF
DiegoDAF marked this pull request as ready for review December 5, 2025 18:50
Comment thread pgcli/main.py Outdated
message = "Destructive statements must be run within a transaction. Command execution stopped."
return [(None, None, None, message)]
destroy = confirm_destructive_query(query, self.destructive_warning, self.dsn_alias)
if self.force_destructive:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than check self.force_destructive in two places, I'd change the signature of confirm_destructive_query to include it as a parameter.

DiegoDAF added 2 commits July 20, 2026 12:27
Address review feedback: instead of checking self.force_destructive at both
call sites, confirm_destructive_query now takes a `force` parameter and owns
the whole 'should we proceed?' decision.

Behaviour is unchanged: non-destructive returns None, force returns True,
a non-tty stdin returns None (no prompt), otherwise the user is prompted.
The parameter defaults to False, so existing callers are unaffected.
DiegoDAF added a commit to DiegoDAF/pgcli.daf that referenced this pull request Jul 20, 2026
Port of the review feedback on upstream PR dbcli#1544. Instead of checking
self.force_destructive at both call sites (execute_from_file and
execute_command), confirm_destructive_query now takes a `force` parameter and
owns the whole "should we proceed?" decision:

  non-destructive -> None
  force           -> True
  non-tty stdin   -> None (no prompt)
  otherwise       -> prompt the user

Behaviour is unchanged. The parameter defaults to False, so existing callers
are unaffected. The only remaining self.force_destructive reference is the
guard that suppresses the "Your call!" message, which is about output, not the
proceed/abort decision.

Also closes roadmap item dbcli#4 (Conexiones) in todo.md as redundant: post-connect
SQL and .pg_service.conf already exist, keepalives/connect_timeout already work
via the connection string, and SSL ~ expansion has no practical need.

No version bump (held at 4.5.7 per Diego).
test_force_destructive_skips_confirmation asserted that
confirm_destructive_query was never called with -y. Now that the helper takes
the force parameter it IS called and decides internally not to prompt, so the
old assertion encoded the previous structure rather than the behaviour.

It now patches prompt_utils.confirm and asserts the user is never prompted,
which is the actual guarantee -y makes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants