您的位置:  首页 > 技术杂谈 > 正文

MySQL 大战 PostgreSQL 第二回:呆瓜模式的分歧

2024-03-01 19:00 https://my.oschina.net/u/6148470/blog/11045408 Bytebase 次阅读 条评论

file

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

MySQL 的呆瓜模式

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

PostgreSQL 的呆瓜模式

Postgres 命令行 psql 没有提供呆瓜模式。社区曾经有用户尝试直接在 Server 端加一个类似的限制,但是被驳回了。

file

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

file

Bytebase 的呆瓜模式

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

file

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

file

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

file

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

file

回到 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。

file

而我会拒绝那个 PG 补丁的理由是因为在 Server 端加限制的话,打击面太广,还是由不同的客户端根据各自场景来决定比较好。也欢迎大家在评论区里一起讨论。


💡 更多资讯,请关注 Bytebase 公号:Bytebase

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接