PostgreSQL的设计傲慢：为什么“强大“不能成为“难用“的借口

PostgreSQL的设计傲慢：为什么"强大"不能成为"难用"的借口

当工具的设计者沉浸在自我满足中时，用户体验就成了第一个牺牲品

在技术圈里，PostgreSQL 几乎成了"正确性"的代名词。无数文章赞美它的 SQL 标准符合度、它的高级功能、它的稳定性。但今天，我想谈谈这个"优等生"的另一面——那些被狂热粉丝刻意忽略的设计缺陷，以及背后反映出的工程傲慢。

"所有权限"不等于所有权限：一个语义的悖论

让我们从一个最简单的例子开始：

-- 在 PostgreSQL 中，你可能会这样做：
CREATE DATABASE my_app;
CREATE USER app_admin WITH PASSWORD 'secret';
GRANT ALL PRIVILEGES ON DATABASE my_app TO app_admin;

任何讲英语的人都会认为：ALL PRIVILEGES 意味着所有权限。但当你用 app_admin 用户连接数据库后，你会发现：

• ❌ 不能在 public schema 中创建表
• ❌ 不能查询已有的表
• ❌ 甚至不能使用序列（如果你有自增字段）

这就像餐厅告诉你"所有菜品任选"，但当你点菜时却说：“哦，你需要先获得使用盘子的权限，然后是使用刀叉的权限，最后是咀嚼的权限…”

真正的"所有权限"应该是什么样？

-- 理想的一键授权：
GRANT FULL_ACCESS ON DATABASE my_app TO app_admin;

-- 或者至少应该这样：
GRANT ALL PRIVILEGES ON DATABASE my_app TO app_admin WITH CASCADE;

技术上实现这个有多难？几乎为零。这只是一个简单的命令包装器，底层仍然可以保持细粒度的权限控制。但 PostgreSQL 就是不做。

系统表命名：历史包袱还是设计失误？

另一个让人费解的设计是系统表的命名：

-- 这些是 PostgreSQL 的系统表，不是你的业务表！
SELECT * FROM user;    -- 系统用户表
SELECT * FROM table;   -- 系统表信息
SELECT * FROM group;   -- 系统组信息

-- 结果你不得不这样命名自己的表：
CREATE TABLE app_user (...);     -- 加前缀
CREATE TABLE business_table (...); -- 加前缀
CREATE TABLE user_group (...);   -- 还是冲突！

这就像在编程语言中把 class、function、variable 作为保留字一样荒谬。更合理的做法应该是：

-- 系统表应该有自己的命名空间
SELECT * FROM pg_catalog.users;
SELECT * FROM pg_catalog.tables;
SELECT * FROM pg_catalog.groups;

-- 或者使用统一前缀
SELECT * FROM pg_users;
SELECT * FROM pg_tables; 

渐进式复杂度的缺失

PostgreSQL 支持者常说的一个论点是：“细粒度权限控制对于企业级应用很重要。”

这完全正确！但问题是：为什么不能让简单的事情保持简单？

一个好的系统应该支持渐进式复杂度：

PostgreSQL 的问题在于，它强迫所有用户从最复杂的级别开始。这就像学开车时，教练第一天就教你修理变速箱。

“设计哲学”：为糟糕体验辩护的万能借口

当我向 PostgreSQL 爱好者提出这些问题时，最常听到的回复是：

• “这是设计哲学”
• “为了数据安全”
• “你应该理解它的权限模型”

这让我想起了那个经典的笑话：

用户：“这个按钮为什么是红色的？”

设计师：“这是我们的设计哲学。”

用户：“但用户找不到这个按钮。”

设计师：“那你应该理解我们的设计哲学。”

真正的设计哲学应该是什么？

1. 符合直觉：功能行为应该符合大多数用户的预期
2. 渐进披露：基础用法简单，高级功能在需要时学习
3. 语义一致：说是什么，就是什么

与其他数据库的对比

让我们公平地说，MySQL 也有自己的问题（比如历史上对SQL标准的忽视）。但在用户体验方面，它确实做得更好：

-- MySQL 中的权限管理直观得多
GRANT ALL PRIVILEGES ON my_db.* TO 'user'@'host';
-- 用户真的获得了所有权限！

-- 系统表也有清晰的命名空间
SELECT * FROM information_schema.users;
SELECT * FROM information_schema.tables;

这不是说 MySQL 更好，而是说 PostgreSQL 完全有能力做得更好，但选择不做。

技术圈的"受虐倾向"

我发现技术圈有一种奇怪的现象：有些人以掌握复杂、反直觉的工具为荣。

• “我知道 PostgreSQL 权限的10个坑” ➡️ 沾沾自喜
• “我花了3天配置好权限” ➡️ 成就感满满
• “你们觉得难是因为不懂设计哲学” ➡️ 优越感爆棚

这就像以"我能用螺丝刀吃米饭"为荣一样荒谬。好的工具应该增强用户的能力，而不是考验用户的能力。

constructive 批评：PostgreSQL 可以怎样改进

我的批评不是要否定 PostgreSQL 的全部价值，而是希望它变得更好：

1. 提供真正的一次性授权命令

   GRANT FULL ON DATABASE db_name TO user_name;
   

2. 重构系统表命名

   -- 保持向后兼容，但推荐新命名
   SELECT * FROM pg_users;  -- 新的系统表名
   

3. 改进默认配置

   • 新数据库默认给所有者所有权限
   • 简化开发环境的权限配置

4. 更好的错误信息

   • 当权限不足时，告诉用户具体需要什么权限
   • 提供修复命令的建议

结语：强大不应该等于难用

PostgreSQL 确实很强大——就像一栋由著名建筑师设计的豪华房屋。但如果这栋房子的门需要特殊的开门技巧，窗户需要复杂的操作流程，那么无论它内部多么豪华，对居住者来说都是一种折磨。

我们需要停止用"强大"为"难用"辩护。一个真正优秀的系统应该在保持强大的同时，也让简单的事情保持简单。

毕竟，技术的终极目标应该是让人更强大，而不是让工具更复杂。

后记：我知道这篇文章会引来很多 PostgreSQL 爱好者的批评。但如果你要反驳，请直接回答这个问题：为什么GRANT ALL PRIVILEGES不应该意味着真正的所有权限？