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

2024年 3月 12日 40.1k 0

今天再聊一个 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 端加限制的话,打击面太广,还是由不同的客户端根据各自场景来决定比较好。

相关文章

Oracle如何使用授予和撤销权限的语法和示例
Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
下载丨66页PDF,云和恩墨技术通讯(2024年7月刊)
社区版oceanbase安装
Oracle 导出CSV工具-sqluldr2
ETL数据集成丨快速将MySQL数据迁移至Doris数据库

发布评论