Extensions

PostgreSQL is an extensible database. The same APIs the backend uses internally — Table AM, Index AM, FDW, output plugins, hooks — are available to loadable shared libraries. The repository ships two flavors of in-tree extensions:

• Procedural languages — under src/pl/. Plug-in languages for stored procedures: PL/pgSQL, PL/Perl, PL/Python, PL/Tcl.
• Contrib modules — under contrib/. Optional extensions that ship with the server: full-text search, FDWs, performance tools, helper datatypes, file format readers, pseudo-random functions, etc.

This section gives an overview of each. The Procedural languages page walks the PLs; the Contrib modules page surveys the dozens of contrib extensions.

Why two locations?

Historically:

• src/pl/ is the home of in-tree procedural languages because they are tightly integrated with the executor (via SPI) and need to be built alongside the server.
• contrib/ is the staging area for "first-party but optional" features. Anything in contrib/ is built and packaged but not loaded automatically; users CREATE EXTENSION <name> to install it.

Many features have graduated into core from contrib/ — tsearch2 (full-text search), the int8 type (long ago), declarative partitioning (which displaced pg_partman-style approaches). Other features have stabilized in contrib/ and stayed there because they are useful but optional (postgres_fdw, pg_stat_statements).

Extensibility surface

The server exposes a wide set of extension points. The major ones:

Extension point	Source	What it customizes
Procedural language	src/pl/, pg_language catalog	Implements the C-side language handler called by CREATE FUNCTION ... LANGUAGE foo.
C function	(anywhere)	CREATE FUNCTION name(...) RETURNS ... AS '/path/lib', 'sym' LANGUAGE C.
Foreign data wrapper	src/backend/foreign/ + extension	Tables backed by external storage.
Index access method	src/backend/access/ + extension via RegisterCustomXxx	New index methods (e.g., pgvector, bloom).
Table access method	src/backend/access/table/ + extension	Alternative row storage.
Custom scan	src/backend/executor/nodeCustomScan.c + extension	Inject custom plan + executor nodes.
Output plugin (logical decoding)	src/backend/replication/logical/ + extension	Custom CDC formats.
Background worker	src/backend/postmaster/bgworker.c + extension	Custom helper processes.
Custom WAL resource manager	src/backend/access/transam/rmgr.c + extension	New WAL record types.
Hooks	various	Function pointers in core code that an extension can override.
GUC	src/backend/utils/misc/guc.c + extension	Add new server parameters.

Creating a new extension

Extensions are SQL+C packages laid out as:

myext/
├── myext.control            # name, version, dependencies, schema
├── myext--1.0.sql           # initial schema script
├── myext--1.0--1.1.sql      # upgrade script (optional)
├── myext.c                  # C code
├── myext--unpackaged--1.0.sql  # for upgrades from pre-extension
└── Makefile                 # uses pgxs.mk

The Makefile typically uses PGXS:

EXTENSION = myext
DATA = myext--1.0.sql
MODULES = myext

PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)

Building produces myext.so + the .control and .sql files. Install into the server's extension directory; users then CREATE EXTENSION myext;.

src/test/modules/ and contrib/*/ are the canonical reference implementations. contrib/dummy_index_am/ is a tutorial-style minimal index AM.

Hooks

Many subsystems expose hook function pointers that an extension can install:

• planner_hook, set_rel_pathlist_hook, set_join_pathlist_hook — planner.
• ExecutorStart_hook, ExecutorRun_hook, ExecutorFinish_hook, ExecutorEnd_hook — executor.
• ProcessUtility_hook — DDL dispatch.
• ClientAuthentication_hook — auth.
• emit_log_hook — logging.
• shmem_startup_hook / shmem_request_hook — shared-memory allocation.
• object_access_hook — object-permission checks.

Most hooks are simple "save the previous value, override with our own that calls through to the previous." This composes cleanly across multiple loaded extensions. The hook declarations are in the relevant subsystem's headers.

shared_preload_libraries

Extensions that need to start a background worker, allocate shared memory, or install hooks must be loaded at server start. The shared_preload_libraries GUC is a comma-separated list of libraries the postmaster dlopens before forking any backends. Each library's _PG_init() runs in the postmaster process.

Pages in this section

• Procedural languages — PL/pgSQL, PL/Perl, PL/Python, PL/Tcl.
• Contrib modules — survey of the optional in-tree extensions.