mirror of
https://github.com/postgres/postgres.git
synced 2025-05-03 22:24:49 +03:00
Fix obsolete references to old-style contrib installation methods.
This commit is contained in:
parent
2ee69ff65d
commit
f1fb4b0e63
@ -17,8 +17,13 @@
|
||||
below) while creating a trigger.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Each of the groups of functions described below is provided as a
|
||||
separately-installable extension.
|
||||
</para>
|
||||
|
||||
<sect2>
|
||||
<title>refint.c — Functions for Implementing Referential Integrity</title>
|
||||
<title>refint — Functions for Implementing Referential Integrity</title>
|
||||
|
||||
<para>
|
||||
<function>check_primary_key()</> and
|
||||
@ -59,7 +64,7 @@
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>timetravel.c — Functions for Implementing Time Travel</title>
|
||||
<title>timetravel — Functions for Implementing Time Travel</title>
|
||||
|
||||
<para>
|
||||
Long ago, <productname>PostgreSQL</> had a built-in time travel feature
|
||||
@ -152,7 +157,7 @@ CREATE TABLE mytab (
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>autoinc.c — Functions for Autoincrementing Fields</title>
|
||||
<title>autoinc — Functions for Autoincrementing Fields</title>
|
||||
|
||||
<para>
|
||||
<function>autoinc()</> is a trigger that stores the next value of
|
||||
@ -179,7 +184,7 @@ CREATE TABLE mytab (
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>insert_username.c — Functions for Tracking Who Changed a Table</title>
|
||||
<title>insert_username — Functions for Tracking Who Changed a Table</title>
|
||||
|
||||
<para>
|
||||
<function>insert_username()</> is a trigger that stores the current
|
||||
@ -200,7 +205,7 @@ CREATE TABLE mytab (
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>moddatetime.c — Functions for Tracking Last Modification Time</title>
|
||||
<title>moddatetime — Functions for Tracking Last Modification Time</title>
|
||||
|
||||
<para>
|
||||
<function>moddatetime()</> is a trigger that stores the current
|
||||
|
@ -46,38 +46,45 @@
|
||||
<para>
|
||||
Many modules supply new user-defined functions, operators, or types.
|
||||
To make use of one of these modules, after you have installed the code
|
||||
you need to register the new objects in the database
|
||||
system by running the SQL commands in the <literal>.sql</> file
|
||||
supplied by the module. For example,
|
||||
you need to register the new SQL objects in the database system.
|
||||
In <productname>PostgreSQL</> 9.1 and later, this is done by executing
|
||||
a <xref linkend="sql-createextension"> command. In a fresh database,
|
||||
you can simply do
|
||||
|
||||
<programlisting>
|
||||
psql -d dbname -f <replaceable>SHAREDIR</>/contrib/<replaceable>module</>.sql
|
||||
CREATE EXTENSION <replaceable>module_name</>;
|
||||
</programlisting>
|
||||
|
||||
Here, <replaceable>SHAREDIR</> means the installation's <quote>share</>
|
||||
directory (<literal>pg_config --sharedir</> will tell you what this is).
|
||||
In most cases the script must be run by a database superuser.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You need to run the <literal>.sql</> file in each database that you want
|
||||
This command must be run by a database superuser. This registers the
|
||||
new SQL objects in the current database only, so you need to run this
|
||||
command in each database that you want
|
||||
the module's facilities to be available in. Alternatively, run it in
|
||||
database <literal>template1</> so that the module will be copied into
|
||||
database <literal>template1</> so that the extension will be copied into
|
||||
subsequently-created databases by default.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can modify the first command in the <literal>.sql</> file to determine
|
||||
which schema within the database the module's objects will be created in.
|
||||
By default, they will be placed in <literal>public</>.
|
||||
Many modules allow you to install their objects in a schema of your
|
||||
choice. To do that, add <literal>SCHEMA
|
||||
<replaceable>schema_name</></literal> to the <command>CREATE EXTENSION</>
|
||||
command. By default, the objects will be placed in your current creation
|
||||
target schema, typically <literal>public</>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After a major-version upgrade of <productname>PostgreSQL</>, run the
|
||||
installation script again, even though the module's objects might have
|
||||
been brought forward from the old installation by dump and restore.
|
||||
This ensures that any new functions will be available and any needed
|
||||
corrections will be applied.
|
||||
If your database was brought forward by dump and reload from a pre-9.1
|
||||
version of <productname>PostgreSQL</>, and you had been using the pre-9.1
|
||||
version of the module in it, you should instead do
|
||||
|
||||
<programlisting>
|
||||
CREATE EXTENSION <replaceable>module_name</> FROM unpackaged;
|
||||
</programlisting>
|
||||
|
||||
This will update the pre-9.1 objects of the module into a proper
|
||||
<firstterm>extension</> object. Future updates to the module will be
|
||||
managed by <xref linkend="sql-alterextension">.
|
||||
For more information about extension updates, see
|
||||
<xref linkend="extend-extensions">.
|
||||
</para>
|
||||
|
||||
&adminpack;
|
||||
|
@ -47,8 +47,8 @@
|
||||
<title>Usage</title>
|
||||
|
||||
<para>
|
||||
Running the installation script creates a text search template
|
||||
<literal>intdict_template</> and a dictionary <literal>intdict</>
|
||||
Installing the <literal>dict_int</> extension creates a text search
|
||||
template <literal>intdict_template</> and a dictionary <literal>intdict</>
|
||||
based on it, with the default parameters. You can alter the
|
||||
parameters, for example
|
||||
|
||||
|
@ -87,8 +87,8 @@ word syn1 syn2 syn3
|
||||
<title>Usage</title>
|
||||
|
||||
<para>
|
||||
Running the installation script creates a text search template
|
||||
<literal>xsyn_template</> and a dictionary <literal>xsyn</>
|
||||
Installing the <literal>dict_xsyn</> extension creates a text search
|
||||
template <literal>xsyn_template</> and a dictionary <literal>xsyn</>
|
||||
based on it, with default parameters. You can alter the
|
||||
parameters, for example
|
||||
|
||||
|
@ -10,7 +10,7 @@
|
||||
<para>
|
||||
The <filename>earthdistance</> module provides two different approaches to
|
||||
calculating great circle distances on the surface of the Earth. The one
|
||||
described first depends on the <filename>cube</> package (which
|
||||
described first depends on the <filename>cube</> module (which
|
||||
<emphasis>must</> be installed before <filename>earthdistance</> can be
|
||||
installed). The second one is based on the built-in <type>point</> data type,
|
||||
using longitude and latitude for the coordinates.
|
||||
|
@ -553,12 +553,6 @@ SELECT key, count(*) FROM
|
||||
<sect2>
|
||||
<title>Compatibility</title>
|
||||
|
||||
<para>
|
||||
<emphasis>When upgrading from older versions, always load the new
|
||||
version of this module into the database before restoring a dump.
|
||||
Otherwise, many new features will be unavailable.</emphasis>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As of PostgreSQL 9.0, <type>hstore</> uses a different internal
|
||||
representation than previous versions. This presents no obstacle for
|
||||
|
@ -148,7 +148,7 @@
|
||||
<para>
|
||||
This view, and the function <function>pg_stat_statements_reset</>,
|
||||
are available only in databases they have been specifically installed into
|
||||
by running the <filename>pg_stat_statements.sql</> install script.
|
||||
by installing the <literal>pg_stat_statements</> extension.
|
||||
However, statistics are tracked across all databases of the server
|
||||
whenever the <filename>pg_stat_statements</filename> module is loaded
|
||||
into the server, regardless of presence of the view.
|
||||
|
@ -345,7 +345,9 @@ FROM crosstab3(
|
||||
<listitem>
|
||||
<para>
|
||||
Create a composite type describing the desired output columns,
|
||||
similar to the examples in the installation script. Then define a
|
||||
similar to the examples in
|
||||
<filename>contrib/tablefunc/tablefunc--1.0.sql</>.
|
||||
Then define a
|
||||
unique function name accepting one <type>text</> parameter and returning
|
||||
<type>setof your_type_name</>, but linking to the same underlying
|
||||
<function>crosstab</> C function. For example, if your source data
|
||||
|
@ -35,8 +35,8 @@ mydb=# SELECT * FROM ts_token_type('testparser');
|
||||
<title>Usage</title>
|
||||
|
||||
<para>
|
||||
Running the installation script creates a text search parser
|
||||
<literal>testparser</>. It has no user-configurable parameters.
|
||||
Installing the <literal>test_parser</> extension creates a text search
|
||||
parser <literal>testparser</>. It has no user-configurable parameters.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -152,7 +152,7 @@
|
||||
<emphasis>before</> loading the dump data! If your old installation
|
||||
had the <application>tsearch2</> objects in a schema other
|
||||
than <literal>public</>, be sure to adjust the
|
||||
<literal>tsearch2</literal> installation script so that the replacement
|
||||
<command>CREATE EXTENSION</> command so that the replacement
|
||||
objects are created in that same schema.
|
||||
</para>
|
||||
</step>
|
||||
|
@ -73,7 +73,7 @@
|
||||
<title>Usage</title>
|
||||
|
||||
<para>
|
||||
Running the installation script <filename>unaccent.sql</> creates a text
|
||||
Installing the <literal>unaccent</> extension creates a text
|
||||
search template <literal>unaccent</> and a dictionary <literal>unaccent</>
|
||||
based on it. The <literal>unaccent</> dictionary has the default
|
||||
parameter setting <literal>RULES='unaccent'</>, which makes it immediately
|
||||
|
Loading…
x
Reference in New Issue
Block a user