今天再聊一個 MySQL 和 Postgres 之間小小的不同，呆瓜模式的實現(xiàn)。

1.MySQL 的呆瓜模式

圖片

MySQL 命令行工具提供了一個選項 --safe-updates 或者 --i-am-a-dummy，默認是 false。開啟之后如果 UPDATE, DELETE 不帶 WHERE 或者 LIMIT 就會報錯。此外 SELECT 語句也可以指定返回超過一定行數(shù)后報錯。

2.PostgreSQL 的呆瓜模式

Postgres 命令行 psql 沒有提供呆瓜模式。社區(qū)曾經(jīng)有用戶嘗試直接在 Server 端加一個類似的限制，但是被駁回了 https://www.postgresql.org/message-id/flat/1580673.1675373572%40sss.pgh.pa.us#48697ecc933fe79695d7bc5db7badf9f

圖片

社區(qū)于是又想了個曲線救國的方法，實現(xiàn)了一個 safeupdate extension，來達到類似的效果。

圖片

3.Bytebase 的呆瓜模式

Bytebase 也有類似的呆瓜模式，能同時應(yīng)用到 MySQL 和 PostgreSQL 及其他支持的數(shù)據(jù)庫上。用戶在 Bytebase SQL Editor 的普通模式進行非 SELECT 操作是被禁止的。

圖片

如果是普通開發(fā)者的話，就必須走工單審核流程。

圖片

如果是 DBA，則也可以選擇進入管理員模式再執(zhí)行。

圖片

同時也可以在 SQL 審核規(guī)則中配置必須要有 WHERE，否則就報錯。

圖片

圖片

回到 MySQL 和 PostgreSQL 在呆瓜模式上的區(qū)別，我自己還是更喜歡 MySQL 的方案，也希望在 psql 中也提供類似的選項。不過筆者覺得 PG 社區(qū)拒掉 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 應(yīng)該還是開發(fā)活干的少，低估了日常中低級錯誤發(fā)生的頻率。比如下面這樣只選中了一部分語句執(zhí)行，漏了后面的 WHERE。

圖片

而我會拒絕那個 PG 補丁的理由是因為在 Server 端加限制的話，打擊面太廣，還是由不同的客戶端根據(jù)各自場景來決定比較好。