PostgreSQL 7.3.3 文档
PrevChapter 2. 数据定义Next

2.8. 模式

一个 PostgreSQL 数据库集群（安装） 包含一个或多个命名的数据库。用户和用户组在整个集群的范围内 是共享的，但是其它数据并不是共享的。任何给定的与服务器的客户连接都只 能访问在一个数据库里的数据，就是那个在连接请求里声明的。

注意: 一个集群的用户并不一定要有访问集群内所有数据库的权限。 共享用户名的意思是不能有同名用户，也就是，在同一个集群里的两个 数据库里都有叫 joe 的用户；但是系统可以配置成 只允许 joe 访问某些数据库。

一个数据库包含一个或多个命名的 模式， 模式又包含表。模式还包含其它命名的对象，包括数据类型，函数， 以及操作符。同一个对象名可以在不同的模式里使用而不会导致冲突； 比如，schema1 和 myschema 都可以包含叫做 mytable 的表。和数据库不同，模式不是严格分离的： 一个用户可以访问他所连接的数据库种的任意模式种的对象， 只要他有权限。

我们需要模式的原因有好多：

模式类似于操作系统层次的目录，只不过模式不能嵌套。

2.8.1. 创建一个模式

要创建一个独立的模式，使用命令 CREATE SCHEMA。 给出你选择的模式名字。比如： 

CREATE SCHEMA myschema;

要创建或者访问在模式中的对象，写出一个受修饰的名字， 这个名字包含模式名以及表（对象名），它们之间用一个句点分开： 

schema.table

实际上，更一般的语法是 

database.schema.table

这个语法也可以使用，但目前它只是为了和 SQL 标准形式上兼容； 如果你写了一个数据库名，那么它必须和你当前连接的数据库同名。

要在新模式里创建一个表，用 

CREATE TABLE myschema.mytable (
 ...
);

这样的方法在任何需要一个表名字的地方都可以用， 包括修改表的命令和我们在下一章要讲的数据访问命令。

如果一个模式是空的（所有它里面的对象都已经删除），那么删除一个模式的命令 

DROP SCHEMA myschema;

要删除一个包含所有对象的模式，使用 

DROP SCHEMA myschema CASCADE;

参阅 Section 2.10 获取躲藏在这些动作背后 的东西的一般机制的描述。

通常你想创建一个别人拥有的模式（因为这是一种限制你的用户 在定义良好的模式中的活动的方法）。其语法如下： 

CREATE SCHEMA schemaname AUTHORIZATION username;

你甚至可以省略模式名字，这时模式名将和用户名同名。 参阅 Section 2.8.6 获取这种情况 的适用场合。

以 pg_ 开头的模式名是保留给系统使用的， 用户不能创建这样的名字。

2.8.2. Public 模式

在前面的小节里，我们没有声明任何模式名字就创建了表。 缺省时，这样的表（以及其他对象）都自动放到一个叫做"public" 的模式中去了。每个新数据库都包含一个这样的模式。因此，下面的命令是等效的： 

CREATE TABLE products ( ... );

和 

CREATE TABLE public.products ( ... );

2.8.3. 模式搜索路径

全称的名字写起来非常费劲，并且我们最好不要在应用里直接 写上特定的模式名。因此，表通常都是拥未修饰的名字 引用的，这样的名字里只有表名字。系统通过查找一个搜索路径 来判断一个表究竟是哪个表，这个路径是一个需要查找的模式列表。 在搜索路径里找到的第一个表将被当作选定的表。如果在搜索路径中 没有匹配表，那么就报告一个错误，即使匹配表的名字在数据库其它的 模式中存在也如此。

在搜索路径中的第一个模式叫做当前模式。除了是搜索的第一个模式之外， 它还是在 CREATE TABLE 没有声明模式名的时候，新建表 所在的地方。

要现实当前搜索路径，使用下面的命令： 

SHOW search_path;

在缺省的设置中，返回下面的东西： 

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

第一个元素声明将要搜索一个和当前用户同名的模式。 因为还没有这样的模式存在，所以这条记录被忽略。第二个元素指向 我们已经看过的公共模式。

搜索路径中存在的第一个模式是创建新对象的缺省位置。 这就是为什么缺省的对象都会创建在 public 模式里的原因。 如果在任何其它环境中引用对象，而且没有用模式修饰 （表修改，数据变更，或者查询命令），那么系统会遍历 搜索路径，直到找到一个匹配的对象。因此，在缺省的配置里， 任何未修饰的访问同样也只能引用 public 模式。

要把新的模式放到路径中来，我们用 

SET search_path TO myschema,public;

（我们在这里省略乐 $user 是因为我们 并不是立即需要它。）然后我们就可以不用加模式修饰访问 表了： 

DROP TABLE mytable;

同样，因为 myschema 是路径中的第一个元素， 新对象缺省时将创建在这里。

我们也可以写成 

SET search_path TO myschema;

然后我们如果不明确修饰的话，就不能再访问 public 模式了。 public 模式没有任何特殊之处，只不过它缺省时就存在。 我们也可以把它删除了。

又见 Section 6.13 获取其它访问模式搜索路径的方法。

搜索路径对于数据类型名，函数名以及操作符名的运作方式和表名字完全相同。 数据类型和函数名可以象表名字一样加以修饰。如果你需要再表达式里写一个 有修饰的操作符名字，我们有一个特殊的要求：你必须这么写 

OPERATOR(schema.operator)

这样是为了避免语法歧义。下面是一个例子 

SELECT 3 OPERATOR(pg_catalog.+) 4;

实际上我们通常依赖搜索路径寻找操作符， 这样就不用写这么难看的东西了。

2.8.4. 模式和权限

缺省时，用户看不到模式中不属于他们所有的对象。 为了让他们看得见，模式的所有者需要在模式上赋予 USAGE 权限。为了让用户使用模式中的对象，我们可能需要赋予额外的权限， 只要是适合该对象的。

用户也可以允许在别人的模式里创建对象。要允许这么做， 我们需要赋予在该模式上的 CREATE 权限。 请注意，缺省时，每个人都在 public 模式上 有 CREATE 权限。这样就允许所有可以连接到 指定数据库上的用户在这里创建对象。如果你不允许这么做， 你可以撤销这个权限： 

REVOKE CREATE ON public FROM PUBLIC;

（第一个 "public" 是模式，第二个 "public" 意思是"所有用户"。 第一个是个标识符，而第二个是个保留字，所以有不同的大小写； 记住我们在 Section 1.1.1 里面 说过的原则。）

2.8.5. 系统表模式

除了 public 和用户创建的模式之外， 每个数据库都包含一个 pg_catalog 模式，它包含 系统表和所有内置数据类型，函数和操作符。pg_catalog 总是搜索路径中的一部分。如果它没有明确出现在路径中，那么 它会隐含地在路径里地模式之前搜索。这样就保证了内置地名字 总是可以搜索地。不过，你可以明确地把pg_catalog 放在你的搜索路径的后面，如果你想用用户定义的名字覆盖内置的名字的话。

在 PostgreSQL 版本 7.3 之前， 以 pg_ 开头的表名字是保留的。这个规则现在 不再是正确的了：如果必要，你可以创建这样的表名字， 只要是在非系统模式里。不过，我们最好还是不要使用这样的名字， 以保证自己将来不会和新版本冲突：那些版本也许会定义一些和 你的表同名的表。（在缺省搜索路径中，一个对你的表的无修饰 引用将解析未系统表。）系统表将继续遵循以pg_ 开头的传统，因此，只要你的表不是以pg_ 开头， 就不会和无修饰的用户表名字冲突。

2.8.6. 使用方式

模式可以以多种方式组织你的数据。下面是一些建议使用的模式， 它们也很容易在缺省配置中得到支持：

2.8.7. 移植性

在 SQL 标准里，在同一个模式里的对象由不同的用户所有的概念是不存在的。 而且，有些实现不允许你创建和它们的所有者不同名的模式。实际上， 模式和用户的概念在那些只实现了标准中规定的基本模式支持的数据库系统里几乎是一样的。 因此，许多用户考虑对名字加以修饰，使它们真正由 username.tablename组成。 如果你为每个用户都创建了一个模式，这实际上就是 PostgreSQL 的行为。

同样，在 SQL 标准里也没有 public 模式的概念。 为了最大限度地遵循标准，你不应该使用（可能甚至是应该删除） public 模式。

当然，有些 SQL 数据库系统可能根本没有实现模式，或者是通过允许 （可能是有限制的）跨数据库访问来提供模式的支持。 如果你需要在这些系统上干活，那么最大限度的移植性来自根本不用模式。

PrevHomeNext
权限Up其它数据库对象