is
     used inside a string literal, such as a function body or
     a <varname>search_path</varname> setting.  In other cases, the object
     reference is reduced to an OID during parsing and does not require
     subsequent lookups.)  If the other extension's schema name is so
     embedded, you should prevent the other extension from being relocated
     after yours is installed, by adding the name of the other extension to
     this one's <literal>no_relocate</literal> list.
    </para>
   </sect2>

   <sect2 id="extend-extensions-config-tables">
    <title>Extension Configuration Tables</title>

    <para>
     Some extensions include configuration tables, which contain data that
     might be added or changed by the user after installation of the
     extension.  Ordinarily, if a table is part of an extension, neither
     the table's definition nor its content will be dumped by
     <application>pg_dump</application>.  But that behavior is undesirable for a
     configuration table; any data changes made by the user need to be
     included in dumps, or the extension will behave differently after a dump
     and restore.
    </para>

   <indexterm>
    <primary>pg_extension_config_dump</primary>
   </indexterm>

    <para>
     To solve this problem, an extension's script file can mark a table
     or a sequence it has created as a configuration relation, which will
     cause <application>pg_dump</application> to include the table's or the sequence's
     contents (not its definition) in dumps.  To do that, call the function
     <function>pg_extension_config_dump(regclass, text)</function> after creating the
     table or the sequence, for example
<programlisting>
CREATE TABLE my_config (key text, value text);
CREATE SEQUENCE my_config_seq;

SELECT pg_catalog.pg_extension_config_dump('my_config', '');
SELECT pg_catalog.pg_extension_config_dump('my_config_seq', '');
</programlisting>
     Any number of tables or sequences can be marked this way. Sequences
     associated with <type>serial</type> or <type>bigserial</type> columns can
     be marked as well.
    </para>

    <para>
     When the second argument of <function>pg_extension_config_dump</function> is
     an empty string, the entire contents of the table are dumped by
     <application>pg_dump</application>.  This is usually only correct if the table
     is initially empty as created by the extension script.  If there is
     a mixture of initial data and user-provided data in the table,
     the second argument of <function>pg_extension_config_dump</function> provides
     a <literal>WHERE</literal> condition that selects the data to be dumped.
     For example, you might do
<programlisting>
CREATE TABLE my_config (key text, value text, standard_entry boolean);

SELECT pg_catalog.pg_extension_config_dump('my_config', 'WHERE NOT standard_entry');
</programlisting>
     and then make sure that <structfield>standard_entry</structfield> is true only
     in the rows created by the extension's script.
    </para>

    <para>
     For sequences, the second argument of <function>pg_extension_config_dump</function>
     has no effect.
    </para>

    <para>
     More complicated situations, such as initially-provided rows that might
     be modified by users, can be handled by creating triggers on the
     configuration table to ensure that modified rows are marked correctly.
    </para>

    <para>
     You can alter the filter condition associated with a configuration table
     by calling <function>pg_extension_config_dump</function> again.  (This would
     typically be useful in an extension update script.)  The only way to mark
     a table as no longer a configuration table is to dissociate it from the
     extension with <command>ALTER EXTENSION ... DROP TABLE</command>.
    </para>

    <para>
     Note that foreign key relationships between these tables will dictate the
     order in which the tables are dumped out by pg_dump.  Specifically, pg_dump