feature: dangerous statement detection

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

noe.trevino/dadbod-ui.nvim#96

noe.trevino commented

2026-07-15 17:49:01 -05:00

Owner

Did you check the docs?

I have read all the dadbod-ui.nvim docs

Nothing stops me from running delete from users when i meant to type a where clause. Or a drop i thought was pointed somewhere else. One keystroke and its gone.

Describe the solution you'd like

Look at the statement before it runs. If its a DROP, or an UPDATE or DELETE with no WHERE, confirm with vim.ui.confirm first.

Builds on the statement classifier from #92. Patterns come from the adapter spec since dialects differ.

The nice thing about this one is it needs no setup. No flag to remember to set, no connection to mark. It protects everything the moment it exists, which is exactly what you want for someone who just installed the plugin.

Acceptance Criteria

catches DROP
catches UPDATE with no WHERE
catches DELETE with no WHERE
confirms with vim.ui.confirm
saying no does not run the statement
saying no to one statement in a script stops the script, doesnt skip to the next one
the prompt says which table its about to hit
user can turn it off
implemented in all adapters where their cli allows
- postgres
- MySQL
- MariaDB
- SQL Server
- SQLite

Describe alternatives/other solutions you've considered

DBeaver ties their version to a connection type, so you only get it on connections you marked prod. Its also weaker than it sounds, it skips selects entirely, you can yes-to-all it, and saying no just continues to the next statement in the script. The version that isnt tied to any config is the better one.

Relying on read only connections (#92) instead. That only protects connections i remembered to mark. This protects everything with no setup. They do different jobs.

Whether you can turn it off per connection or only globally isnt decided yet. Patterns are per adapter for sure.

Blocked by

#101

### Did you check the docs? - [X] I have read all the dadbod-ui.nvim docs ### Is your feature request related to a problem? Please describe. Nothing stops me from running `delete from users` when i meant to type a where clause. Or a drop i thought was pointed somewhere else. One keystroke and its gone. ### Describe the solution you'd like Look at the statement before it runs. If its a DROP, or an UPDATE or DELETE with no WHERE, confirm with `vim.ui.confirm` first. Builds on the statement classifier from #92. Patterns come from the adapter spec since dialects differ. The nice thing about this one is it needs no setup. No flag to remember to set, no connection to mark. It protects everything the moment it exists, which is exactly what you want for someone who just installed the plugin. ### Acceptance Criteria - [ ] catches DROP - [ ] catches UPDATE with no WHERE - [ ] catches DELETE with no WHERE - [ ] confirms with `vim.ui.confirm` - [ ] saying no does not run the statement - [ ] saying no to one statement in a script stops the script, doesnt skip to the next one - [ ] the prompt says which table its about to hit - [ ] user can turn it off - [ ] implemented in all adapters where their cli allows - [ ] postgres - [ ] MySQL - [ ] MariaDB - [ ] SQL Server - [ ] SQLite ### Describe alternatives/other solutions you've considered DBeaver ties their version to a connection type, so you only get it on connections you marked prod. Its also weaker than it sounds, it skips selects entirely, you can yes-to-all it, and saying no just continues to the next statement in the script. The version that isnt tied to any config is the better one. Relying on read only connections (#92) instead. That only protects connections i remembered to mark. This protects everything with no setup. They do different jobs. Whether you can turn it off per connection or only globally isnt decided yet. Patterns are per adapter for sure. ### Blocked by - #101

Rows
Columns

feature: dangerous statement detection #96

Did you check the docs?

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Acceptance Criteria

Describe alternatives/other solutions you've considered

Blocked by