1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-31 22:04:40 +03:00

extension_control_path

The new GUC extension_control_path specifies a path to look for
extension control files.  The default value is $system, which looks in
the compiled-in location, as before.

The path search uses the same code and works in the same way as
dynamic_library_path.

Some use cases of this are: (1) testing extensions during package
builds, (2) installing extensions outside security-restricted
containers like Python.app (on macOS), (3) adding extensions to
PostgreSQL running in a Kubernetes environment using operators such as
CloudNativePG without having to rebuild the base image for each new
extension.

There is also a tweak in Makefile.global so that it is possible to
install extensions using PGXS into an different directory than the
default, using 'make install prefix=/else/where'.  This previously
only worked when specifying the subdirectories, like 'make install
datadir=/else/where/share pkglibdir=/else/where/lib', for purely
implementation reasons.  (Of course, without the path feature,
installing elsewhere was rarely useful.)

Author: Peter Eisentraut <peter@eisentraut.org>
Co-authored-by: Matheus Alcantara <matheusssilv97@gmail.com>
Reviewed-by: David E. Wheeler <david@justatheory.com>
Reviewed-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Reviewed-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Reviewed-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Discussion: https://www.postgresql.org/message-id/flat/E7C7BFFB-8857-48D4-A71F-88B359FADCFD@justatheory.com
This commit is contained in:
Peter Eisentraut
2025-03-19 06:57:20 +01:00
parent 2cce0fe440
commit 4f7f7b0375
13 changed files with 526 additions and 199 deletions

View File

@ -10954,6 +10954,74 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
</listitem>
</varlistentry>
<varlistentry id="guc-extension-control-path" xreflabel="extension_control_path">
<term><varname>extension_control_path</varname> (<type>string</type>)
<indexterm>
<primary><varname>extension_control_path</varname> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<para>
A path to search for extensions, specifically extension control files
(<filename><replaceable>name</replaceable>.control</filename>). The
remaining extension script and secondary control files are then loaded
from the same directory where the primary control file was found.
See <xref linkend="extend-extensions-files"/> for details.
</para>
<para>
The value for <varname>extension_control_path</varname> must be a
list of absolute directory paths separated by colons (or semi-colons
on Windows). If a list element starts
with the special string <literal>$system</literal>, the
compiled-in <productname>PostgreSQL</productname> extension
directory is substituted for <literal>$system</literal>; this
is where the extensions provided by the standard
<productname>PostgreSQL</productname> distribution are installed.
(Use <literal>pg_config --sharedir</literal> to find out the name of
this directory.) For example:
<programlisting>
extension_control_path = '/usr/local/share/postgresql/extension:/home/my_project/share/extension:$system'
</programlisting>
or, in a Windows environment:
<programlisting>
extension_control_path = 'C:\tools\postgresql\extension;H:\my_project\share\extension;$system'
</programlisting>
Note that the path elements should typically end in
<literal>extension</literal> if the normal installation layouts are
followed. (The value for <literal>$system</literal> already includes
the <literal>extension</literal> suffix.)
</para>
<para>
The default value for this parameter is
<literal>'$system'</literal>. If the value is set to an empty
string, the default <literal>'$system'</literal> is also assumed.
</para>
<para>
This parameter can be changed at run time by superusers and users
with the appropriate <literal>SET</literal> privilege, but a
setting done that way will only persist until the end of the
client connection, so this method should be reserved for
development purposes. The recommended way to set this parameter
is in the <filename>postgresql.conf</filename> configuration
file.
</para>
<para>
Note that if you set this parameter to be able to load extensions from
nonstandard locations, you will most likely also need to set <xref
linkend="guc-dynamic-library-path"/> to a correspondent location, for
example,
<programlisting>
extension_control_path = '/usr/local/share/postgresql/extension:$system'
dynamic_library_path = '/usr/local/lib/postgresql:$libdir'
</programlisting>
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-gin-fuzzy-search-limit" xreflabel="gin_fuzzy_search_limit">
<term><varname>gin_fuzzy_search_limit</varname> (<type>integer</type>)
<indexterm>

View File

@ -649,6 +649,11 @@ RETURNS anycompatible AS ...
control file can specify a different directory for the script file(s).
</para>
<para>
Additional locations for extension control files can be configured using
the parameter <xref linkend="guc-extension-control-path"/>.
</para>
<para>
The file format for an extension control file is the same as for the
<filename>postgresql.conf</filename> file, namely a list of
@ -669,9 +674,9 @@ RETURNS anycompatible AS ...
<para>
The directory containing the extension's <acronym>SQL</acronym> script
file(s). Unless an absolute path is given, the name is relative to
the installation's <literal>SHAREDIR</literal> directory. The
default behavior is equivalent to specifying
<literal>directory = 'extension'</literal>.
the installation's <literal>SHAREDIR</literal> directory. By default,
the script files are looked for in the same directory where the
control file was found.
</para>
</listitem>
</varlistentry>
@ -719,8 +724,8 @@ RETURNS anycompatible AS ...
<para>
The value of this parameter will be substituted for each occurrence
of <literal>MODULE_PATHNAME</literal> in the script file(s). If it is not
set, no substitution is made. Typically, this is set to
<literal>$libdir/<replaceable>shared_library_name</replaceable></literal> and
set, no substitution is made. Typically, this is set to just
<literal><replaceable>shared_library_name</replaceable></literal> and
then <literal>MODULE_PATHNAME</literal> is used in <command>CREATE
FUNCTION</command> commands for C-language functions, so that the script
files do not need to hard-wire the name of the shared library.
@ -1804,6 +1809,10 @@ include $(PGXS)
setting <varname>PG_CONFIG</varname> to point to its
<command>pg_config</command> program, either within the makefile
or on the <literal>make</literal> command line.
You can also select a separate installation directory for your extension
by setting the <literal>make</literal> variable <varname>prefix</varname>
on the <literal>make</literal> command line. (But this will then require
additional setup to get the server to find the extension there.)
</para>
<para>

View File

@ -90,8 +90,10 @@ CREATE EXTENSION [ IF NOT EXISTS ] <replaceable class="parameter">extension_name
<para>
The name of the extension to be
installed. <productname>PostgreSQL</productname> will create the
extension using details from the file
<literal>SHAREDIR/extension/</literal><replaceable class="parameter">extension_name</replaceable><literal>.control</literal>.
extension using details from the file <filename><replaceable
class="parameter">extension_name</replaceable>.control</filename>,
found via the server's extension control path (set by <xref
linkend="guc-extension-control-path"/>.)
</para>
</listitem>
</varlistentry>