postgres_fdw 在首次执行使用与某个外部服务器关联的 外部表的查询时，会建立到该外部服务器的连接。默认情况下，该连接会在同一 会话中保留并供后续查询重用。这一行为可通过外部服务器的 keep_connections 选项控制。如果使用多个用户标识 （用户映射）访问该外部服务器，则会为每个用户映射建立一个连接。

当更改外部服务器或用户映射的定义，或将其删除时，相关连接会被关闭。 但请注意，如果任何连接在当前本地事务中正在使用，则会保留到事务结束。 关闭的连接会在后续使用外部表的查询需要它们时重新建立。

一旦与外部服务器建立连接，默认情况下它会一直保留到本地会话或对应的 远程会话退出。要显式断开连接，可以禁用外部服务器的 keep_connections 选项，或使用 postgres_fdw_disconnect 和 postgres_fdw_disconnect_all 函数。例如，这些函数 可用于关闭不再需要的连接，从而释放外部服务器上的连接资源。

在引用某个外部服务器上任意远程表的查询期间，如果当前本地事务尚未在该 远程服务器上打开对应的事务，postgres_fdw 就会在 该远程服务器上打开一个事务。本地事务提交或中止时，远程事务也会提交或 中止。保存点也会通过创建对应的远程保存点进行类似管理。

当本地事务的隔离级别为 SERIALIZABLE 时，远程事务使用 SERIALIZABLE；否则使用 REPEATABLE READ 隔离级别。这一选择确保如果一个查询 在远程服务器上执行多次表扫描，所有扫描都能获得快照一致的结果。其结果是， 同一事务中的后续查询会看到来自远程服务器的相同数据，即使远程服务器由于 其他活动正在发生并发更新。对于使用 SERIALIZABLE 或 REPEATABLE READ 隔离级别的本地事务，这种行为本来就 符合预期；但对于 READ COMMITTED 本地事务，则可能令人 意外。未来的 PostgreSQL 版本可能会修改这些 规则。

请注意，postgres_fdw 当前不支持将远程事务预备为 两阶段提交。

postgres_fdw 会尽力优化远程查询，以减少从外部 服务器传输的数据量。这是通过将查询的 WHERE 子句发送到 远程服务器执行，以及不获取当前查询不需要的表列来实现的。为降低查询被 错误执行的风险，除非 WHERE 子句仅使用内置数据类型、 操作符和函数，或属于外部服务器 extensions 选项列出的 扩展，否则不会将其发送到远程服务器。这类子句中的操作符和函数还必须是 IMMUTABLE。对于 UPDATE 或 DELETE 查询，postgres_fdw 会在 查询中不存在无法发送到远程服务器的 WHERE 子句、没有 本地连接操作、目标表上没有行级本地 BEFORE 或 AFTER 触发器或存储生成列，也没有来自父视图的 CHECK OPTION 约束时，尝试将整个查询发送到远程服务器 以优化执行。在 UPDATE 中，为了降低查询被错误执行的 风险，赋给目标列的表达式也必须只使用内置数据类型、 IMMUTABLE 操作符或 IMMUTABLE 函数。

当 postgres_fdw 遇到同一外部服务器上的外部表之间的 连接时，除非由于某种原因它认为分别从各表取回行会更高效，或者相关表引用 受不同用户映射约束，否则会将整个连接发送到远程服务器。在发送 JOIN 子句时，它也会采取与前述 WHERE 子句相同的预防措施。

可以使用 EXPLAIN VERBOSE 查看实际发送给远程服务器 执行的查询。

在 postgres_fdw 打开的远程会话中， search_path 参数会被设置为仅包含 pg_catalog，这样无需模式限定就只能看到内置对象。 这对 postgres_fdw 自身生成的查询不是问题，因为它 总是提供这种限定。然而，这可能会对那些通过远程表上的触发器或规则在 远程服务器上执行的函数带来风险。例如，如果远程表实际上是一个视图， 则该视图中使用的任何函数都会在受限的搜索路径下执行。建议在这类函数中 对所有名称都写成带模式限定的形式，或者为这类函数附加 SET search_path 选项（见 CREATE FUNCTION），以建立其预期的搜索路径环境。

postgres_fdw 还会为远程会话设置以下参数：

这些设置通常不像 search_path 那样容易出问题，但如果有 需要，也可以通过函数的 SET 选项处理。

不建议通过修改这些参数的会话级设置来覆盖这种行为； 这很可能导致 postgres_fdw 工作异常。

postgres_fdw 可用于最早追溯到 PostgreSQL 8.3 的远程服务器。只读能力可追溯到 8.1。 不过有一个限制是，postgres_fdw 通常假定： 如果外部表的 WHERE 子句中出现不可变的内置函数和 操作符，那么把它们发送到远程服务器执行是安全的。因此，某个在远程服务器 所属发行版本之后才加入的内置函数，可能仍会被发送到该远程服务器执行， 从而导致“function does not exist”或类似错误。可以通过 重写查询绕过这类失败，例如把外部表引用放入一个带 OFFSET 0 的子 SELECT 中，作为优化 栅栏，并将有问题的函数或操作符放到子 SELECT 之外。

postgres_fdw 可以在等待事件类型 Extension 下报告以下等待事件：

下面是使用 postgres_fdw 创建外部表的一个示例。 首先安装扩展：

CREATE EXTENSION postgres_fdw;

然后使用 CREATE SERVER 创建外部服务器。 在本示例中，希望连接到一台 PostgreSQL 服务器， 它运行在主机 192.83.123.89 上并监听 5432 端口。要连接的数据库在远程服务器上名为 foreign_db：

CREATE SERVER foreign_server
        FOREIGN DATA WRAPPER postgres_fdw
        OPTIONS (host '192.83.123.89', port '5432', dbname 'foreign_db');

还需要用 CREATE USER MAPPING 定义一个用户映射， 以标识在远程服务器上使用哪个角色：

CREATE USER MAPPING FOR local_user
        SERVER foreign_server
        OPTIONS (user 'foreign_user', password 'password');

现在就可以使用 CREATE FOREIGN TABLE 创建外部表了。 在本示例中，希望访问远程服务器上名为 some_schema.some_table 的表。它在本地的名称将是 foreign_table：

CREATE FOREIGN TABLE foreign_table (
        id integer NOT NULL,
        data text
)
        SERVER foreign_server
        OPTIONS (schema_name 'some_schema', table_name 'some_table');

在 CREATE FOREIGN TABLE 中声明的列的数据类型和其他属性， 必须与实际远程表匹配。列名也必须匹配，除非为各个列附加 column_name 选项来指明它们在远程表中的名称。 在许多情况下，相比手工构造外部表定义，使用 IMPORT FOREIGN SCHEMA 更可取。

Shigeru Hanada <shigeru.hanada@gmail.com>