Redrock Postgres 搜索 英文
版本: 9.3 / 9.4 / 9.5 / 9.6 / 10 / 11 / 12 / 13 / 14 / 15 / 16

5.8. 模式

5.8.1. 创建模式
5.8.2. 公共模式
5.8.3. 模式搜索路径
5.8.4. 模式和权限
5.8.5. 系统目录模式
5.8.6. 惯用法
5.8.7. 可移植性

一个PostgreSQL数据库集簇中包含一个或更多命名的数据库。用户和用户组被整个集簇共享,但没有其他数据在数据库之间共享。任何给定客户端连接只能访问在连接中指定的数据库中的数据。

注意

一个集簇的用户并不必拥有访问集簇中每一个数据库的权限。用户名的共享意味着不可能在同一个集簇中出现重名的不同用户,例如两个数据库中都有叫joe的用户。但系统可以被配置为只允许joe访问某些数据库。

一个数据库包含一个或多个命名模式,模式中包含着表。模式还包含其他类型的命名对象,包括数据类型、函数和操作符。相同的对象名称可以被用于不同的模式中而不会出现冲突,例如schema1myschema都可以包含名为mytable的表。和数据库不同,模式并不是被严格地隔离:一个用户可以访问他们所连接的数据库中的所有模式内的对象,只要他们有足够的权限。

下面是一些使用模式的原因:

模式类似于操作系统层的目录,但是模式不能嵌套。

5.8.1. 创建模式

要创建一个模式,可使用CREATE SCHEMA命令,并且给出选择的模式名称。例如:

CREATE SCHEMA myschema;

在一个模式中创建或访问对象,需要使用由模式名和表名构成的限定名,模式名和表名之间以点号分隔:

模式.

在任何需要一个表名的地方都可以这样用,包括表修改命令和后续章节要讨论的数据访问命令(为了简洁我们在这里只谈到表,但是这种方式对其他类型的命名对象同样有效,例如类型和函数)。

事实上,还有更加通用的语法:

数据库.模式.

也可以使用,但是目前它只是在形式上与SQL标准兼容。如果我们写一个数据库名称,它必须是我们正在连接的数据库。

因此,如果要在一个新模式中创建一个表,可用:

CREATE TABLE myschema.mytable (
 ...
);

要删除一个为空的模式(其中的所有对象已经被删除),可用:

DROP SCHEMA myschema;

要删除一个模式以及其中包含的所有对象,可用:

DROP SCHEMA myschema CASCADE;

有关于此的更一般的机制请参见第 5.13 节

我们常常希望创建一个由其他人所拥有的模式(因为这是将用户动作限制在良定义的名字空间中的方法之一)。其语法是:

CREATE SCHEMA schema_name AUTHORIZATION user_name;

我们甚至可以省略模式名称,在此种情况下模式名称将会使用用户名,参见第 5.8.6 节

pg_开头的模式名被保留用于系统目的,所以不能被用户所创建。

5.8.2. 公共模式

在前面的小节中,我们创建的表都没有指定任何模式名称。默认情况下这些表(以及其他对象)会自动的被放入一个名为public的模式中。任何新数据库都包含这样一个模式。因此,下面的命令是等效的:

CREATE TABLE products ( ... );

以及:

CREATE TABLE public.products ( ... );

5.8.3. 模式搜索路径

限定名写起来很冗长,通常最好不要把一个特定模式名拉到应用中。因此,表名通常被使用非限定名来引用,它只由表名构成。系统将沿着一条搜索路径来决定该名称指的是哪个表,搜索路径是一个进行查看的模式列表。 搜索路径中第一个匹配的表将被认为是所需要的。如果在搜索路径中没有任何匹配,即使在数据库的其他模式中存在匹配的表名也将会报告一个错误。

搜索路径中的第一个模式被称为当前模式。除了是第一个被搜索的模式外,如果CREATE TABLE命令没有指定模式名,它将是新创建表所在的模式。

要显示当前搜索路径,使用下面的命令:

SHOW search_path;

在默认设置下这将返回:

 search_path
--------------
 "$user",public

第一个元素说明一个和当前用户同名的模式会被搜索。如果不存在这个模式,该项将被忽略。第二个元素指向我们已经见过的公共模式。

搜索路径中的第一个模式是创建新对象的默认存储位置。这就是默认情况下对象会被创建在公共模式中的原因。当对象在任何其他没有模式限定的环境中被引用(表修改、数据修改或查询命令)时,搜索路径将被遍历直到一个匹配对象被找到。因此,在默认配置中,任何非限定访问将只能指向公共模式。

要把新模式放在搜索路径中,我们可以使用:

SET search_path TO myschema,public;

(我们在这里省略了$user,因为我们并不立即需要它)。然后我们可以该表而无需使用模式限定:

DROP TABLE mytable;

同样,由于myschema是路径中的第一个元素,新对象会被默认创建在其中。

我们也可以这样写:

SET search_path TO myschema;

这样我们在没有显式限定时再也不必去访问公共模式了。公共模式没有什么特别之处,它只是默认存在而已,它也可以被删除。

其他操作模式搜索路径的方法请见第 9.25 节

搜索路径对于数据类型名称、函数名称和操作符名称的作用与表名一样。数据类型和函数名称可以使用和表名完全相同的限定方式。如果我们需要在一个表达式中写一个限定的操作符名称,我们必须写成一种特殊的形式:

OPERATOR(schema.operator)

这是为了避免句法歧义。例如:

SELECT 3 OPERATOR(pg_catalog.+) 4;

实际上我们通常都会依赖于搜索路径来查找操作符,因此没有必要去写如此“丑陋”的东西。

5.8.4. 模式和权限

默认情况下,用户不能访问不属于他们的模式中的任何对象。要允许这种行为,模式的拥有者必须在该模式上授予USAGE权限。为了允许用户使用模式中的对象,可能还需要根据对象授予额外的权限。

一个用户也可以被允许在其他某人的模式中创建对象。要允许这种行为,模式上的CREATE权限必须被授予。注意在默认情况下,所有人都拥有在public模式上的CREATEUSAGE权限。这使得用户能够连接到一个给定数据库并在它的public模式中创建对象。如果不希望允许这样,可以撤销该权限:

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

(第一个public是模式,第二个public指的是 每一个用户。第一种是一个标识符,第二种是一个关键词,所以两者的大小写不同。请回想第 4.1.1 节中的指导方针。)

5.8.5. 系统目录模式

public和用户创建的模式之外,每一个数据库还包括一个pg_catalog模式,它包含了系统表和所有内建的数据类型、函数以及操作符。pg_catalog总是搜索路径的一个有效部分。如果没有在路径中显式地包括该模式,它将在路径中的模式之前被搜索。这保证了内建的名称总是能被找到。然而,如果我们希望用用户定义的名称重载内建的名称,可以显式的将pg_catalog放在搜索路径的末尾。

由于系统表名称以pg_开头,最好还是避免使用这样的名称,以避免和未来新版本中 可能出现的系统表名发生冲突。系统表将继续采用以pg_开头的方式,这样它们不会 与非限制的用户表名称冲突。

5.8.6. 惯用法

模式可以被用来以多种方式组织我们的数据。在默认配置下,一些常见的用法是:

  • 如果我们不创建任何模式则所有用户会隐式地访问公共模式。这就像根本不存在模式一样。当数据库中只有一个用户或者少量合作用户时,推荐使用这种配置。这种配置使得我们很容易从没有模式的环境中转换过来。

  • 我们可以为每一个用户创建与它同名的模式。回想一下,默认的搜索路径以$user开始,它将会被解析成用户名。因此,如果每一个用户有一个独立的模式,它们将会默认访问自己的模式。

    如果我们使用这种配置,则我们可能也希望撤销到公共模式的访问(或者把它也一起删除),这样用户被真正地限制在他们自己的模式中。

  • 要安装共享的应用(任何人都可以用的表、由第三方提供的附加函数等),将它们放在独立的模式中。记住要授予适当的权限以允许其他用户访问它们。然后用户就可以使用带模式名的限定名称来引用这些附加对象,或者他们可以把附加模式放入到他们的搜索路径中。

5.8.7. 可移植性

在SQL标准中,在由不同用户拥有的同一个模式中的对象是不存在的。此外,某些实现不允许创建与拥有者名称不同名的模式。事实上,在那些仅实现了标准中基本模式支持的数据库中,模式和用户的概念是等同的。因此,很多用户认为限定名称实际上是由user_name.table_name组成的。如果我们为每一个用户都创建了一个模式,PostgreSQL实际也是这样认为的。

同样,在SQL标准中也没有public模式的概念。为了最大限度的与标准一致,我们不应使用(甚至是删除)public模式。

当然,某些SQL数据库系统可能根本没有实现模式,或者提供允许跨数据库访问的名字空间。如果需要使用这样一些系统,最好不要使用模式。