POSTGRESQL 权限问题，官方说必须是DBOWNER 和 SUPERUSE 才能进行DDL 操作，真的？

PG 14 下的官方文字截图

https://www.postgresql.org/docs/current/ddl-priv.html

题目的问题anwser在最下方， 最近在工作中，有同学告知我，在PG的生产环境中，必须是表的OWNER 或 SUPERUSER 才能对表进行DDL 操作，或者删除操作，事实是这样的，如果不是怎么解决这个问题。

我们先从SCHEMA 开始这个问题。

POSTGRESQL 的权限对比其他的数据库是复杂的，实际上产生于下面的几个问题，如schema  , database owner, 等概念产生的问题，下面根据实际问题来一个一个解释实际生产中遇到的问题。

1   在一个数据库下建立SCEHMA ，同时这个账号不是这个数据库下的DBOWNER，那么有没有可能在这个账号下，在非PUBLIC 的SCHEMA下创建对象

在回答上述问题之前我们需要通过一个思维导图来明确什么是SCHEMA

1.1 什么是SCHEMA

个人理解SCHEMA 是一组用户权限和对象的管理的“文件夹”， 通过在SCHEMA中添加OBJECT 的方式来组织数据库中常见的对象并管理。

1.2 什么样的账号可以创建schema 

超级用户自然可以在数据库下创建schema，同时普通的账号也具有在一个数据库里面创建SCHEMA的权利，比如给付CREATE 权限给这个账号。

实现：我们在一个POSTGRESQL 14的数据库内，创建一个数据库TIMER，并且创建一个数据库用户 new， 并且这个new用户不具有任何的超级权限的情况下，赋予这个new 账号有create schema的权利，同时这个new 账号不是这个数据库的 dbowner.

我们划分两个界面

1  通过POSTGRES 用户登录数据库并创建数据库和用户

2  在下一个界面我们通过NEW 登录到PG中

接下来我们通过new账号登录到timer 数据中，此时我们在 timer中创建一个schema 叫  try ,并尝试让 new 账号在try 的schema中创建一个表。

这里我们并不能通过new  账号在timer数据库中创建try 的schema

new 这个账号并没有创建schema的权利，可以给付他创建SCHEMA的权利，或者通过其他账号给他们创建一个SCHEMA，此时我们通过POSTGRES 账号在timer中创建一个schema ,try 然后我们通过new这个账号创建表，但失败了。

那我们可以给这个new账号赋予在try的schema中创建object的权利。

grant create on schema try to new;

此时在赋予了create  权限给付了new账号后，这个new账号就可以在try schema下创建object了。

此时我们回答上面图的几个问题

不是这个DB的DBOWNER 可以在赋予CREATE SCHEMA 的权限后，对这个database的指定的 schema进行 OBJECT 对象的建立，包含表，存储过程，函数等。

select * from information_schema.table_privileges where table_schema = 'try';

同时也就是我们在执行完grant create on schema to 用户；用户本身就可以具有在这个SCHEMA下拥有的所有的OBJECT 的处理权限，包含对表的insert, select, update ,delete truncate 等权利。

1  dbowner 可以认为是创建这个OBJECT的初创者，在没有复制权限的过程中，除了SUPERUSER 可以操作OBJECT ，dbowner 本身也可以操作他创造出来的OBJECT。

2  账号的变化会对OBJECT 本身有什么变化，尤其对于原有的账号和新的账号。我们做一个实验

2.1  我们创建一个数据库，并且这个数据库本身是通过一个账号建立，并且这个账号是这些OBJECT 的owner，然后我们在新建一个账号，将这些OBJECT的dbowner 进行改变，然后查看相关的变化。

现在我们在timer 数据库中通过new 账号产生了三个表，现在我们创建一个账号OLD，然后将数据库的OWNER 转换为OLD ，查看OBJECT 的变化和相关账号的变化。

create user old password 'old';

alter database timer owner to old;

这里在改变后，我们还使用NEW 来登录数据库，相关的结果还是可以继续添加表，创建表等。                                                                       

那么我们继续将这些表变更owner,看看会不会有什么变化

整体我们将public 和 try 下的表的owner都改变为 old

这里我们发现变更后，new 账号已经失去了对原来表的操控权，说明改变 owner后，会导致原有账号失去对原来有的表的操作权限。

那么我们通过

grant all on schema try to new;

grant all on schema public to new;
两个命令，尝试new 是否可以继续对表具有相关权限，结果是否定的

在我们对表的级别将所有的权限赋予 new  后，虽然这些表new 不是OWNER 但是他有对其的访问，等权利。

那么此时我们回到题目的问题，将一些赋值的操作对new  账号进行操作，看看是否可以，1 不是SUPERUSER 2 不是表的OWNER，同时两个情况下，可以对表进行DDL 操作。

timer=# alter default privileges in schema try grant all on tables to new;
ALTER DEFAULT PRIVILEGES
timer=# grant all privileges on database timer to new;
GRANT
timer=# grant all privileges on all tables in schema try to new;

我们对原表进行了如上的操作，然后在通过下面的NEW 账号持续对表进行alter table 的操作，都不行

并且曾经有人问过这个问题，答复也是不可以，必须是 SUPERUSER 或TABLE OWNER 才可以进行  ALTER 的操作。

此时，翻看一些解决方案，其中有一个方案是通过 grant 的方式来解决。

命令很简单，就是将此时此刻的 TABLE OWNER old 账号的 权限通过 

grant old to new 的方式进行赋予。然后结果就可以进行对原来不是自己table owner得表进行alter table的操作了。

此时再次验证 NEW  OLD 均不是SUPERUSER， 这是不是说，原来官方提出的必须是 SUPERUSER 或 TABLE OWNER 才能对表进行DDL 操作的说法，可以在深入研究。