Question

我有一个PostgreSQL（9.3.5）群集，其中包含以下角色：

dochazka-test=> \du
                              List of roles
 Role name |                   Attributes                   | Member of  
-----------+------------------------------------------------+------------
 1         |                                                | {admin}
 2         |                                                | {passerby}
 active    | Cannot login                                   | {everyone}
 admin     | Cannot login                                   | {everyone}
 dochazka  |                                                | {admin}
 everyone  | Cannot login                                   | {}
 inactive  | Cannot login                                   | {everyone}
 passerby  | Cannot login                                   | {everyone}
 postgres  | Superuser, Create role, Create DB, Replication | {}

（当新用户被添加到应用程序时，前两个条目是动态创建的。）

正如你所看到的，两个角色都是＆＃34; dochazka＆＃34;和＆＃34; 1＆＃34;在＆＃34; admin＆＃34;角色，在每个人的＃34;角色。所有角色都设置为INHERIT。

＆＃34;每个人＆＃34; role具有schema＆＃34; public＆＃34;。

中所有表，函数和序列的所有权限

正如预期的那样，当我以用户＆＃34; dochazka＆＃34;连接时，我可以在数据库中的表上运行SELECT。但是，当我连接到与用户相同的数据库时，我无法运行相同的SELECT＆＃34; 1＆＃34;：

$ psql -U 1 dochazka-test
Password for user 1: 
psql (9.3.5)
Type "help" for help.

dochazka-test=> select * from employees;
ERROR:  permission denied for relation employees

可能是PostgreSQL在数字角色名称方面存在根本问题吗？

Answer 1

标识符和目录使用name类型，类似于varchar但不完全。除非将它们作为标识符引用，否则一些魔法会使名称区分大小写，并且存在一些约束以使得更容易解析SQL字符串，例如在未引用时对第一个字符（例如，不是数字）的限制。

这并不是说你不能使用大写的标识符或以数字开头的标识符。相反，当您执行以下操作时，必须引用有问题的标识符：select * from "0_Foo"。

我的猜测是你要么丢失双引号，要么你正在使用的客户端没有正确引用标识符。（我刚刚测试过，它可以和psql一起使用。）

无论遇到什么问题，我建议不要使用这些标识符，即使它在纸面上受支持，并建议使用更健谈的角色名称，例如server_1。

编辑：或者，您可能没有正确配置权限。

Answer 2

对不起，大家。这个问题没有充分准备。

问题是我（愚蠢地）运行声明

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO everyone

在创建表之前

！

就数字角色名称而言，psql和Perl DBI似乎都没有任何问题。

PostgreSQL 9.3.5数字角色名称

2 个答案: