MySQL 大戰 PostgreSQL ：呆瓜模式的分歧
今天再聊一個 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 端加限制的話，打擊面太廣，還是由不同的客戶端根據各自場景來決定比較好。
