SQLlyRequire a confirmation
✓ functionalAsk for an unmistakable "yes, really" before a non-SELECT statement gets to run.
Ask for an explicit “yes, really” before a data-changing statement runs. It costs a half-second and it buys back the moment a production query was meant for staging.
What the dialog tells you
Before the gate opens, SQLly reads the batch and reports what it found in
unambiguous capitals - WE WILL MAKE UPDATE CHANGES., or
WE WILL MAKE UPDATE, DELETE, AND TRUNCATE CHANGES. when a batch
does several things at once. The verbs it recognizes are
UPDATE, INSERT, DELETE,
TRUNCATE, and MERGE. Any statement that affects
every row - an UPDATE or DELETE with no
WHERE - is called out separately, because that is the shape of the
mistake people actually make.
When it fires
A confirmation is required when any of these is true for the target connection:
- You asked for it - the confirmation setting is on for this connection or one it inherits from.
- The connection is read-only and something non-read reached the gate, so the refusal is surfaced rather than swallowed.
- The batch is unbounded - an
UPDATEorDELETEwith noWHERE- and the connection has not explicitly opted into unbounded mutations. - AI review is required for data-changing queries on this connection.
- Production writes are temporarily unlocked. Every data-changing batch on an unlocked production connection is confirmed, with no exceptions.
It covers every route to execution
The gate sits in front of the run itself, not in front of the Run button, so the same confirmation appears whether the statement came from the editor, a notebook cell, an auto-refreshing result, a Run on… across several connections, or an AI/MCP-proposed action. For a multi-target run, the dialog names every connection the batch is about to touch. Confirm once and the run proceeds; a batch waiting on a confirmation blocks a second attempt on the same tab rather than queueing two copies of itself.