如果您正在考虑分发您的 PostgreSQL 扩展模块,为其设置一个可移植的构建系统可能会相当困难。因此,PostgreSQL 安装提供了一个名为PGXS的扩展构建基础设施,以便简单的扩展模块可以针对已安装的服务器进行简单构建。PGXS主要用于包含 C 代码的扩展,尽管它也可以用于纯 SQL 扩展。请注意,PGXS并非旨在成为一个通用的构建系统框架,可以用来构建任何与 PostgreSQL 接口的软件;它只是自动化了简单服务器扩展模块的常用构建规则。对于更复杂的软件包,您可能需要编写自己的构建系统。
要为您的扩展使用PGXS基础设施,您必须编写一个简单的 makefile。在 makefile 中,您需要设置一些变量并包含全局的PGXSmakefile。这是一个示例,它构建了一个名为 isbn_issn
的扩展模块,该模块由一个包含一些 C 代码的共享库、一个扩展控制文件、一个 SQL 脚本、一个头文件(仅当其他模块可能需要访问扩展函数而无需通过 SQL)和一个文档文本文件组成
MODULES = isbn_issn EXTENSION = isbn_issn DATA = isbn_issn--1.0.sql DOCS = README.isbn_issn HEADERS_isbn_issn = isbn_issn.h PG_CONFIG = pg_config PGXS := $(shell $(PG_CONFIG) --pgxs) include $(PGXS)
最后三行应始终相同。在文件的前面,您需要分配变量或添加自定义 make 规则。
设置以下三个变量之一来指定构建的内容
还可以设置以下变量
EXTENSION
#扩展名;对于每个名称,您必须提供一个
文件,该文件将安装到 extension
.controlprefix
/share/extension
MODULEDIR
#
的子目录,DATA 和 DOCS 文件应安装到该目录中(如果未设置,如果设置了 prefix
/shareEXTENSION
,则默认为 extension
,否则为 contrib
)
DATA
#要安装到
中的随机文件prefix
/share/$MODULEDIR
DATA_built
#要安装到
中的随机文件,这些文件需要先构建prefix
/share/$MODULEDIR
DATA_TSEARCH
#要安装在
下的随机文件prefix
/share/tsearch_data
DOCS
#要安装在
下的随机文件prefix
/doc/$MODULEDIR
HEADERS
HEADERS_built
#要在
下安装(可选地构建)的文件。prefix
/include/server/$MODULEDIR/$MODULE_big
与 DATA_built
不同,HEADERS_built
中的文件不会被 clean
目标删除;如果您想删除它们,还需要将它们添加到 EXTRA_CLEAN
或添加您自己的规则来执行此操作。
HEADERS_$MODULE
HEADERS_built_$MODULE
#要安装在
下的文件(如果指定,则在构建后安装),其中 prefix
/include/server/$MODULEDIR/$MODULE$MODULE
必须是 MODULES
或 MODULE_big
中使用的模块名称。
与 DATA_built
不同,HEADERS_built_$MODULE
中的文件不会被 clean
目标删除;如果您想删除它们,还需要将它们添加到 EXTRA_CLEAN
或添加您自己的规则来执行此操作。
对同一模块或任何组合使用这两个变量都是合法的,除非您在 MODULES
列表中有两个仅相差前缀 built_
的模块名称,这会导致歧义。在那种(希望不太可能)的情况下,您应该只使用 HEADERS_built_$MODULE
变量。
SCRIPTS
#要安装到
中的脚本文件(非二进制文件)prefix
/bin
SCRIPTS_built
#要安装到
中的脚本文件(非二进制文件),这些文件需要先构建prefix
/bin
REGRESS
#回归测试用例列表(不带后缀),请参见下文
REGRESS_OPTS
#要传递给 pg_regress 的其他开关
ISOLATION
#隔离测试用例列表,有关更多详细信息,请参见下文
ISOLATION_OPTS
#要传递给 pg_isolation_regress 的其他开关
TAP_TESTS
#用于定义是否需要运行 TAP 测试的开关,请参见下文
NO_INSTALL
#不定义 install
目标,这对于不需要安装其构建产品的测试模块很有用
NO_INSTALLCHECK
#不定义 installcheck
目标,例如,如果测试需要特殊配置,或者不使用 pg_regress,这很有用
EXTRA_CLEAN
#在 make clean
中要删除的额外文件
PG_CPPFLAGS
#将前置到 CPPFLAGS
PG_CFLAGS
#将附加到 CFLAGS
PG_CXXFLAGS
#将附加到 CXXFLAGS
PG_LDFLAGS
#将前置到 LDFLAGS
PG_LIBS
#将添加到 PROGRAM
链接行
SHLIB_LINK
#将添加到 MODULE_big
链接行
PG_CONFIG
#要构建的 PostgreSQL 安装的 pg_config 程序的路径(通常只是 pg_config
来使用 PATH
中的第一个)
将此 makefile 作为 Makefile
放在保存您的扩展的目录中。然后您可以执行 make
进行编译,然后执行 make install
来安装您的模块。默认情况下,扩展会为 PATH
中找到的第一个 pg_config
程序对应的 PostgreSQL 安装进行编译和安装。您可以通过在 makefile 中或在 make
命令行上将 PG_CONFIG
设置为指向其 pg_config
程序来使用不同的安装。
如果您想将构建目录分开,您也可以在扩展源代码树之外的目录中运行 make
。此过程也称为 VPATH 构建。以下是如何操作的
mkdir build_dir cd build_dir make -f /path/to/extension/source/tree/Makefile make -f /path/to/extension/source/tree/Makefile install
或者,您可以设置一个目录进行 VPATH 构建,其方式与核心代码的构建方式类似。一种方法是使用核心脚本 config/prep_buildtree
。完成此操作后,您可以通过设置 make
变量 VPATH
来进行构建,如下所示
make VPATH=/path/to/extension/source/tree make VPATH=/path/to/extension/source/tree install
此过程可以适用于更多种目录布局。
在 REGRESS
变量中列出的脚本用于对您的模块进行回归测试,可以通过执行 make install
后再执行 make installcheck
来调用。为了使此功能正常工作,您必须有一个正在运行的 PostgreSQL 服务器。REGRESS
中列出的脚本文件必须出现在您扩展目录中名为 sql/
的子目录中。这些文件的扩展名必须是 .sql
,该扩展名不得包含在 makefile 的 REGRESS
列表中。对于每个测试,还应该有一个文件包含预期输出,该文件位于名为 expected/
的子目录中,具有相同的根名称和扩展名 .out
。make installcheck
使用 psql 执行每个测试脚本,并将结果输出与匹配的预期文件进行比较。任何差异都将以 diff -c
格式写入 regression.diffs
文件中。请注意,尝试运行缺少其预期文件的测试将被报告为“问题”,因此请确保您拥有所有预期文件。
在 ISOLATION
变量中列出的脚本用于测试模块在并发会话中的行为,可以通过执行 make install
后再执行 make installcheck
来调用。为了使此功能正常工作,您必须有一个正在运行的 PostgreSQL 服务器。ISOLATION
中列出的脚本文件必须出现在您扩展目录中名为 specs/
的子目录中。这些文件的扩展名必须是 .spec
,该扩展名不得包含在 makefile 的 ISOLATION
列表中。对于每个测试,还应该有一个文件包含预期输出,该文件位于名为 expected/
的子目录中,具有相同的根名称和扩展名 .out
。make installcheck
执行每个测试脚本,并将结果输出与匹配的预期文件进行比较。任何差异都将以 diff -c
格式写入 output_iso/regression.diffs
文件中。请注意,尝试运行缺少其预期文件的测试将被报告为“问题”,因此请确保您拥有所有预期文件。
TAP_TESTS
启用 TAP 测试的使用。每次运行的数据都存在于名为 tmp_check/
的子目录中。有关更多详细信息,请参阅 第 31.4 节。
创建预期文件的最简单方法是创建空文件,然后进行测试运行(当然会报告差异)。检查在 results/
目录(对于 REGRESS
中的测试)或 output_iso/results/
目录(对于 ISOLATION
中的测试)中找到的实际结果文件,如果它们与您对测试的期望相符,则将它们复制到 expected/
中。
如果您在文档中看到任何不正确、与您对特定功能的体验不符或需要进一步澄清的内容,请使用此表单报告文档问题。