Movatterモバイル変換

If you are thinking about distributing yourPostgres Pro extension modules, setting up a portable build system for them can be fairly difficult. Therefore thePostgres Pro installation provides a build infrastructure for extensions, calledPGXS, so that simple extension modules can be built simply against an already installed server.PGXS is mainly intended for extensions that include C code, although it can be used for pure-SQL extensions too. Note thatPGXS is not intended to be a universal build system framework that can be used to build any software interfacing toPostgres Pro; it simply automates common build rules for simple server extension modules. For more complicated packages, you might need to write your own build system.

To use thePGXS infrastructure for your extension, you must write a simple makefile. In the makefile, you need to set some variables and include the globalPGXS makefile. Here is an example that builds an extension module namedisbn_issn, consisting of a shared library containing some C code, an extension control file, an SQL script, an include file (only needed if other modules might need to access the extension functions without going via SQL), and a documentation text file:

MODULES = isbn_issnEXTENSION = isbn_issnDATA = isbn_issn--1.0.sqlDOCS = README.isbn_issnHEADERS_isbn_issn = isbn_issn.hPG_CONFIG = pg_configPGXS := $(shell $(PG_CONFIG) --pgxs)include $(PGXS)

The last three lines should always be the same. Earlier in the file, you assign variables or add custommake rules.

Set one of these three variables to specify what is built:

The following variables can also be set:

Put this makefile asMakefile in the directory which holds your extension. Then you can domake to compile, and thenmake install to install your module. By default, the extension is compiled and installed for thePostgres Pro installation that corresponds to the firstpg_config program found in yourPATH. You can use a different installation by settingPG_CONFIG to point to itspg_config program, either within the makefile or on themake command line.

You can also runmake in a directory outside the source tree of your extension, if you want to keep the build directory separate. This procedure is also called aVPATH build. Here's how:

mkdir build_dircd build_dirmake -f /path/to/extension/source/tree/Makefilemake -f /path/to/extension/source/tree/Makefile install

Alternatively, you can set up a directory for a VPATH build in a similar way to how it is done for the core code. One way to do this is using the core scriptconfig/prep_buildtree. Once this has been done you can build by setting themake variableVPATH like this:

make VPATH=/path/to/extension/source/treemake VPATH=/path/to/extension/source/tree install

This procedure can work with a greater variety of directory layouts.

The scripts listed in theREGRESS variable are used for regression testing of your module, which can be invoked bymake installcheck after doingmake install. For this to work you must have a runningPostgres Pro server. The script files listed inREGRESS must appear in a subdirectory namedsql/ in your extension's directory. These files must have extension.sql, which must not be included in theREGRESS list in the makefile. For each test there should also be a file containing the expected output in a subdirectory namedexpected/, with the same stem and extension.out.make installcheck executes each test script withpsql, and compares the resulting output to the matching expected file. Any differences will be written to the fileregression.diffs indiff -c format. Note that trying to run a test that is missing its expected file will be reported as“trouble”, so make sure you have all expected files.

The scripts listed in theISOLATION variable are used for tests stressing behavior of concurrent session with your module, which can be invoked bymake installcheck after doingmake install. For this to work you must have a runningPostgres Pro server. The script files listed inISOLATION must appear in a subdirectory namedspecs/ in your extension's directory. These files must have extension.spec, which must not be included in theISOLATION list in the makefile. For each test there should also be a file containing the expected output in a subdirectory namedexpected/, with the same stem and extension.out.make installcheck executes each test script, and compares the resulting output to the matching expected file. Any differences will be written to the fileoutput_iso/regression.diffs indiff -c format. Note that trying to run a test that is missing its expected file will be reported as“trouble”, so make sure you have all expected files.

TAP_TESTS enables the use of TAP tests. Data from each run is present in a subdirectory namedtmp_check/.