今天再聊一个 MySQL 和 Postgres 之间小小的不同，呆瓜模式的实现。

1.MySQL 的呆瓜模式

图片

MySQL 命令行工具提供了一个选项 --safe-updates 或者 --i-am-a-dummy，默认是 false。开启之后如果 UPDATE, DELETE 不带 WHERE 或者 LIMIT 就会报错。此外 SELECT 语句也可以指定返回超过一定行数后报错。

2.PostgreSQL 的呆瓜模式

Postgres 命令行 psql 没有提供呆瓜模式。社区曾经有用户尝试直接在 Server 端加一个类似的限制，但是被驳回了 https://www.postgresql.org/message-id/flat/1580673.1675373572%40sss.pgh.pa.us#48697ecc933fe79695d7bc5db7badf9f

图片

社区于是又想了个曲线救国的方法，实现了一个 safeupdate extension，来达到类似的效果。

图片

3.Bytebase 的呆瓜模式

Bytebase 也有类似的呆瓜模式，能同时应用到 MySQL 和 PostgreSQL 及其他支持的数据库上。用户在 Bytebase SQL Editor 的普通模式进行非 SELECT 操作是被禁止的。

图片

如果是普通开发者的话，就必须走工单审核流程。

图片

如果是 DBA，则也可以选择进入管理员模式再执行。

图片

同时也可以在 SQL 审核规则中配置必须要有 WHERE，否则就报错。

图片

图片

回到 MySQL 和 PostgreSQL 在呆瓜模式上的区别，我自己还是更喜欢 MySQL 的方案，也希望在 psql 中也提供类似的选项。不过笔者觉得 PG 社区拒掉 Server 端加呆瓜模式的补丁是合理的，只是原因和审核官 Tom Lane 给的不同。Tom 说

The cases that I actually see reported are not "I left off the WHERE" but more like "I fat-fingered a variable in a sub-select so that it's an outer reference, causing the test to degenerate to WHERE x = x"

Tom 应该还是开发活干的少，低估了日常中低级错误发生的频率。比如下面这样只选中了一部分语句执行，漏了后面的 WHERE。

图片

而我会拒绝那个 PG 补丁的理由是因为在 Server 端加限制的话，打击面太广，还是由不同的客户端根据各自场景来决定比较好。