一个PostgreSQL数据库集簇中包含一个或更多命名的数据库。 角色和一些其他对象类型被整个集簇共享，连接到服务器的客户端只能访问单个数据库中的数据，在连接请求中指定的那一个。
一个集簇的用户并不必拥有访问集簇中每一个数据库的权限。
角色名的共享意味着不可能在同一个集簇中出现重名的不同角色，例如两个数据库中都有叫joe的用户。
但系统可以被配置为只允许joe访问某些数据库。
一个数据库包含一个或多个命名模式，模式中包含着表。模式还包含其他类型的命名对象，包括数据类型、函数和操作符。相同的对象名称可以被用于不同的模式中而不会出现冲突，例如schema1和myschema都可以包含名为mytable的表。和数据库不同，模式并不是被严格地隔离：一个用户可以访问他们所连接的数据库中的所有模式内的对象，只要他们有足够的权限。
下面是一些使用模式的原因：
允许多个用户使用一个数据库并且不会互相干扰。
将数据库对象组织成逻辑组以便更容易管理。
第三方应用的对象可以放在独立的模式中，这样它们就不会与其他对象的名称发生冲突。
模式类似于操作系统层的目录，但是模式不能嵌套。
要创建一个模式，可使用CREATE SCHEMA命令，并且给出选择的模式名称。例如：
CREATE SCHEMA myschema;
在一个模式中创建或访问对象，需要使用由模式名和表名构成的限定名，模式名和表名之间以点号分隔：
schema.table
在任何需要一个表名的地方都可以这样用，包括表修改命令和后续章节要讨论的数据访问命令（为了简洁我们在这里只谈到表，但是这种方式对其他类型的命名对象同样有效，例如类型和函数）。
事实上，还有更加通用的语法：
database.schema.table
也可以使用，但是目前它只是在形式上与SQL标准兼容。如果我们写一个数据库名称，它必须是我们正在连接的数据库。
因此，如果要在一个新模式中创建一个表，可用：
CREATE TABLE myschema.mytable ( ... );
要删除一个为空的模式（其中的所有对象已经被删除），可用：
DROP SCHEMA myschema;
要删除一个模式以及其中包含的所有对象，可用：
DROP SCHEMA myschema CASCADE;
有关于此的更一般的机制请参见第 5.14 节。
我们常常希望创建一个由其他人所拥有的模式（因为这是将用户动作限制在良定义的名字空间中的方法之一）。其语法是：
CREATE SCHEMAschema_nameAUTHORIZATIONuser_name;
我们甚至可以省略模式名称，在此种情况下模式名称将会使用用户名，参见第 5.9.6 节。
以pg_开头的模式名被保留用于系统目的，所以不能被用户所创建。
在前面的小节中，我们创建的表都没有指定任何模式名称。默认情况下这些表（以及其他对象）会自动的被放入一个名为“public”的模式中。任何新数据库都包含这样一个模式。因此，下面的命令是等效的：
CREATE TABLE products ( ... );
以及：
CREATE TABLE public.products ( ... );
限定名写起来很冗长，通常最好不要把一个特定模式名拉到应用中。因此，表名通常被使用非限定名来引用，它只由表名构成。系统将沿着一条搜索路径来决定该名称指的是哪个表，搜索路径是一个进行查看的模式列表。 搜索路径中第一个匹配的表将被认为是所需要的。如果在搜索路径中没有任何匹配，即使在数据库的其他模式中存在匹配的表名也将会报告一个错误。
在不同模式中创建命名相同的对象的能力使得编写每次都准确引用相同对象的查询变得复杂。这也使得用户有可能更改其他用户查询的行为，不管是出于恶意还是无意。由于未经限定的名称在查询中以及在PostgreSQL内部的广泛使用，在search_path中增加一个模式实际上是信任所有在该模式中具有CREATE特权的用户。在你运行一个普通查询时，如果恶意用户可以在搜索路径的模式中创建对象，那么他们将能够控制并执行任意SQL函数的对象，而这些事情就像是你在执行一样。
搜索路径中的第一个模式被称为当前模式。除了是第一个被搜索的模式外，如果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.26 节。
搜索路径对于数据类型名称、函数名称和操作符名称的作用与表名一样。数据类型和函数名称可以使用和表名完全相同的限定方式。如果我们需要在一个表达式中写一个限定的操作符名称，我们必须写成一种特殊的形式：
OPERATOR(schema.operator)
这是为了避免句法歧义。例如：
SELECT 3 OPERATOR(pg_catalog.+) 4;
实际上我们通常都会依赖于搜索路径来查找操作符，因此没有必要去写如此“丑陋”的东西。
默认情况下，用户无法访问他们不拥有的模式中的任何对象。要允许这样做，模式的所有者必须授予该模式上的USAGE权限。
默认情况下，每个人在模式public上都有该权限。要允许用户使用模式中的对象，可能需要授予其他权限，适用于该对象。
用户还可以被允许在别人的模式中创建对象。为了允许这样做，需要授予模式上的CREATE权限。
在从PostgreSQL 14或更早版本升级的数据库中，每个人都有对模式public的权限。
一些使用模式需要撤销该权限：
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
（第一个“public”是模式，第二个“public”表示“每个用户”。 在第一个意义上，它是一个标识符，在第二个意义上，它是一个关键字，因此使用了不同的大写形式； 请回顾第 4.1.1 节中的指南。）
除public和用户创建的模式之外，每一个数据库还包括一个pg_catalog模式，它包含了系统表和所有内建的数据类型、函数以及操作符。pg_catalog总是搜索路径的一个有效部分。如果没有在路径中显式地包括该模式，它将在路径中的模式之前被搜索。这保证了内建的名称总是能被找到。然而，如果我们希望用用户定义的名称重载内建的名称，可以显式的将pg_catalog放在搜索路径的末尾。
由于系统表名称以pg_开头，最好还是避免使用这样的名称，以避免和未来新版本中可能出现的系统表名发生冲突。系统表将继续采用以pg_开头的方式，这样它们不会 与非限制的用户表名称冲突。
模式可用于许多方式来组织数据。
安全模式使用模式可以防止不受信任的用户更改其他用户查询的行为。
当数据库不使用安全模式使用模式时，希望安全查询该数据库的用户会在每个会话开始时采取保护措施。
具体来说，他们会通过将search_path设置为空字符串或以其他方式从search_path中删除可被非超级用户写入的模式来开始每个会话。
有一些使用模式在默认配置下很容易支持：
将普通用户限制在用户私有模式中。
要实现这种模式，首先确保没有模式具有公共CREATE权限。然后，对于每个需要创建非临时对象的用户，
创建一个与该用户同名的模式，例如CREATE SCHEMA alice AUTHORIZATION alice。
（请记住，默认搜索路径以$user开头，该路径解析为用户名。因此，如果每个用户都有一个单独的模式，
则默认情况下他们访问自己的模式。）除非不受信任的用户是数据库所有者或持有CREATEROLE权限，
否则此模式是安全的模式使用模式。
在PostgreSQL 15及更高版本中，默认配置支持此使用模式。
在早期版本中，或者在使用从早期版本升级的数据库时，您需要从public模式中移除公共CREATE权限（执行REVOKE CREATE ON SCHEMA public FROM PUBLIC）。
然后考虑对public模式进行审计，查找与pg_catalog模式中对象名称相似的对象。
通过修改postgresql.conf或通过执行ALTER ROLE ALL SET search_path =
"$user"，将公共模式从默认搜索路径中移除。然后，在公共模式中授予权限以创建。只有合格的名称才会选择公共模式对象。虽然合格的表引用是可以的，但对公共模式中函数的调用可能是不安全或不可靠。如果在公共模式中创建函数或扩展，请使用第一种模式。否则，像第一种模式一样，除非不受信任的用户是数据库所有者或持有CREATEROLE权限，否则是安全的。
保持默认搜索路径，并授予在公共模式中创建的权限。所有用户隐式访问公共模式。这模拟了模式根本不可用的情况，从不具备模式意识的世界平稳过渡。然而，这永远不是一个安全的模式。只有在数据库具有单个用户或少数相互信任的用户时才可接受。在从PostgreSQL 14或更早版本升级的数据库中，这是默认设置。
对于任何一种模式，如果要安装共享的应用（所有人都要用的表、第三方提供的额外函数，等等），可把它们放在单独的模式中。记得授予适当的权限以允许其他用户访问它们。然后用户可以通过以模式名限定名称的方式来引用这些额外的对象，或者他们可以把额外的模式放在自己的搜索路径中。
在SQL标准中，不同用户拥有同一个模式中的对象的概念是不存在的。此外，某些实现不允许创建与拥有者名称不同名的模式。事实上，在那些仅实现了标准中基本模式支持的数据库中，模式和用户的概念是等同的。因此，很多用户认为限定名称实际上是由user_name.table_name
同样，在SQL标准中也没有public模式的概念。为了最大限度的与标准一致，我们不应使用（甚至是删除）public模式。
当然，某些SQL数据库系统可能根本没有实现模式，或者提供（很可能是有限制地）允许跨数据库访问的命名空间。如果需要使用这样的系统，为了获得最好的可移植性，最好不要使用模式。