Chris van Eijk：PostgreSQL 中“必须是表的所有者”：谁有权修改表？
内容提要
PostgreSQL 中“must be owner of table”错误源于当前角色不是表所有者。即使拥有 GRANT ALL 权限，修改表定义仍需所有权；但触发器、外键、TRUNCATE 等操作可由权限覆盖。模式所有者可删除表却无法读写。开发者因角色继承创建了归己所有的表，导致迁移失败。可通过 ALTER TABLE OWNER 或 REASSIGN OWNED 转移所有权，或让会话默认 SET ROLE 为迁移角色。
延伸解读
所有权与权限的本质区别
文章强调，所有权不是一种可授予的权限，而是对象归属关系。即使角色拥有 GRANT ALL，也无法修改表定义，因为修改定义需要所有权。但触发器、外键、TRUNCATE 等操作可由权限覆盖，这意味着权限可以绕过所有权执行某些变更。理解这一区别有助于避免误以为授予所有权限就能进行迁移。
模式所有者的特殊权力与限制
模式所有者可以删除模式内的表，甚至级联删除其他角色的对象，但不能读取或修改表内容。文章实测显示，模式所有者无法对表执行 SELECT 或 ALTER TABLE，但可以 DROP TABLE 和 REVOKE USAGE。这种权力分离意味着模式所有者能控制对象的存亡和访问入口，却不具备数据操作能力。
角色继承导致的混合所有者问题
开发者通过角色继承获得迁移角色的权限，但创建的表归开发者自己所有。当迁移角色尝试修改这些表时，会因不是所有者而失败。文章建议通过查询 pg_class 找出所有者不一致的表，并使用 ALTER TABLE OWNER 或 REASSIGN OWNED 转移所有权，或设置会话默认 SET ROLE 为迁移角色，确保新建表归迁移角色所有。
转移所有权的条件与影响
转移表所有权需要当前所有者执行，且新所有者需具备模式上的 CREATE 权限。文章实测表明，如果当前所有者不能 SET ROLE 到新所有者，操作会失败。转移后，原有的授权会跟随表转移到新所有者名下，但旧所有者的默认权限和已获授权不变。REASSIGN OWNED 可批量转移，但需要同时具备新旧角色的权限。
Q&A
PostgreSQL 报错 'must be owner of table' 是什么意思？
该错误表示当前角色试图修改表定义，但既不是表的所有者，也不是继承所有者的成员、未通过 SET ROLE 切换为所有者，且不是超级用户。它对应 SQLSTATE 42501，与权限不足不同：所有权不是一种可授予的权限，即使拥有 GRANT ALL 也无法绕过。
拥有 GRANT ALL 权限的角色能对表做哪些操作？
GRANT ALL 允许创建触发器、创建外键、执行 TRUNCATE、REINDEX、CLUSTER、VACUUM、ANALYZE 以及 LOCK TABLE 等操作，但无法执行 ALTER TABLE 添加列、修改列、重命名、设置模式、启用行级安全、创建策略、DROP TABLE、COMMENT、CREATE STATISTICS、CREATE RULE 等需要所有权的操作。
除了表的所有者，还有哪些角色可以修改表？
可以修改表的角色包括：继承自所有者的角色、通过 SET ROLE 切换为所有者的角色，以及超级用户。模式所有者、数据库所有者和 pg_maintain 成员均不能修改表定义，但模式所有者可以删除表，数据库所有者可以执行 VACUUM FULL 和 ANALYZE。
为什么团队中会出现表的所有者不一致的情况？
通常是因为开发者通过角色继承获得了迁移角色的权限，但未使用 SET ROLE，直接以自己的登录身份创建表，导致表归开发者所有。而迁移角色并不继承开发者的权限，因此后续迁移时迁移角色无法修改这些表。
如何更改表的所有者？
使用 ALTER TABLE ... OWNER TO ...，由当前所有者执行，且当前所有者必须能够 SET ROLE 为新所有者，新所有者还需对模式有 CREATE 权限。如果当前所有者不是新所有者的成员，则无法转移。对于大量表，可用 REASSIGN OWNED BY old TO new 一次性转移，但需要同时具备两个角色的权限。
如何确保所有表都由迁移角色拥有？
有两种方法：一是通过 ALTER ROLE alice SET ROLE = 'migrator' 让开发者登录时自动切换为迁移角色，这样创建的表归迁移角色所有；二是完全不让开发者拥有迁移角色，由管道以迁移角色登录执行迁移，开发者使用自己的角色。前者方便但会继承所有权限，后者更安全但需调整流程。
