去年写的全方位对比 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