关于数据库:MySQL-大战-PostgreSQL-第二回呆瓜模式的分歧

去年写的全方位比照 Postgres 和 MySQL 引发了社区里不少的探讨。明天再聊一个 MySQL 和 Postgres 之间小小的不同，呆瓜模式的实现。

MySQL 的呆瓜模式

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

PostgreSQL 的呆瓜模式

Postgres 命令行 psql 没有提供呆瓜模式。社区已经有用户尝试间接在 Server 端加一个相似的限度，然而被驳回了。

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

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 端加限度的话，打击面太广，还是由不同的客户端依据各自场景来决定比拟好。也欢送大家在评论区里一起探讨。

更多资讯，请关注 Bytebase 公号：Bytebase