|
46 | 46 | <para>
|
47 | 47 | Many modules supply new user-defined functions, operators, or types.
|
48 | 48 | To make use of one of these modules, after you have installed the code
|
49 |
| - you need to register the new objects in the database |
50 |
| - system by running the SQL commands in the <literal>.sql</> file |
51 |
| - supplied by the module. For example, |
| 49 | + you need to register the new SQL objects in the database system. |
| 50 | + In <productname>PostgreSQL</> 9.1 and later, this is done by executing |
| 51 | + a <xref linkend="sql-createextension"> command. In a fresh database, |
| 52 | + you can simply do |
52 | 53 |
|
53 | 54 | <programlisting>
|
54 |
| -psql -d dbname -f <replaceable>SHAREDIR</>/contrib/<replaceable>module</>.sql |
| 55 | +CREATE EXTENSION <replaceable>module_name</>; |
55 | 56 | </programlisting>
|
56 | 57 |
|
57 |
| - Here, <replaceable>SHAREDIR</> means the installation's <quote>share</> |
58 |
| - directory (<literal>pg_config --sharedir</> will tell you what this is). |
59 |
| - In most cases the script must be run by a database superuser. |
60 |
| - </para> |
61 |
| - |
62 |
| - <para> |
63 |
| - You need to run the <literal>.sql</> file in each database that you want |
| 58 | + This command must be run by a database superuser. This registers the |
| 59 | + new SQL objects in the current database only, so you need to run this |
| 60 | + command in each database that you want |
64 | 61 | the module's facilities to be available in. Alternatively, run it in
|
65 |
| - database <literal>template1</> so that the module will be copied into |
| 62 | + database <literal>template1</> so that the extension will be copied into |
66 | 63 | subsequently-created databases by default.
|
67 | 64 | </para>
|
68 | 65 |
|
69 | 66 | <para>
|
70 |
| - You can modify the first command in the <literal>.sql</> file to determine |
71 |
| - which schema within the database the module's objects will be created in. |
72 |
| - By default, they will be placed in <literal>public</>. |
| 67 | + Many modules allow you to install their objects in a schema of your |
| 68 | + choice. To do that, add <literal>SCHEMA |
| 69 | + <replaceable>schema_name</></literal> to the <command>CREATE EXTENSION</> |
| 70 | + command. By default, the objects will be placed in your current creation |
| 71 | + target schema, typically <literal>public</>. |
73 | 72 | </para>
|
74 | 73 |
|
75 | 74 | <para>
|
76 |
| - After a major-version upgrade of <productname>PostgreSQL</>, run the |
77 |
| - installation script again, even though the module's objects might have |
78 |
| - been brought forward from the old installation by dump and restore. |
79 |
| - This ensures that any new functions will be available and any needed |
80 |
| - corrections will be applied. |
| 75 | + If your database was brought forward by dump and reload from a pre-9.1 |
| 76 | + version of <productname>PostgreSQL</>, and you had been using the pre-9.1 |
| 77 | + version of the module in it, you should instead do |
| 78 | + |
| 79 | +<programlisting> |
| 80 | +CREATE EXTENSION <replaceable>module_name</> FROM unpackaged; |
| 81 | +</programlisting> |
| 82 | + |
| 83 | + This will update the pre-9.1 objects of the module into a proper |
| 84 | + <firstterm>extension</> object. Future updates to the module will be |
| 85 | + managed by <xref linkend="sql-alterextension">. |
| 86 | + For more information about extension updates, see |
| 87 | + <xref linkend="extend-extensions">. |
81 | 88 | </para>
|
82 | 89 |
|
83 | 90 | &adminpack;
|
|
0 commit comments