diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml
index df3b9d9cb2..f050ff1f66 100644
--- a/doc/src/sgml/extend.sgml
+++ b/doc/src/sgml/extend.sgml
@@ -698,17 +698,21 @@ SET LOCAL search_path TO @extschema@;
To solve this problem, an extension's script file can mark a table
- it has created as a configuration table, which will cause
- pg_dump> to include the table's contents (not its
- definition) in dumps. To do that, call the function
+ or a sequence it has created as a configuration relation, which will
+ cause pg_dump> to include the table's or the sequence's
+ contents (not its definition) in dumps. To do that, call the function
pg_extension_config_dump(regclass, text)> after creating the
- table, for example
+ table or the sequence, for example
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', '');
- Any number of tables can be marked this way.
+ Any number of tables or sequences can be marked this way. Sequences
+ associated with serial> or bigserial> columns can
+ be marked as well.
@@ -729,6 +733,11 @@ SELECT pg_catalog.pg_extension_config_dump('my_config', 'WHERE NOT standard_entr
in the rows created by the extension's script.
+
+ For sequences, the second argument of pg_extension_config_dump>
+ has no effect.
+
+
More complicated situations, such as initially-provided rows that might
be modified by users, can be handled by creating triggers on the
@@ -753,6 +762,12 @@ SELECT pg_catalog.pg_extension_config_dump('my_config', 'WHERE NOT standard_entr
out but the dump will not be able to be restored directly and user
intervention will be required.
+
+
+ Sequences associated with serial> or bigserial> columns
+ need to be directly marked to dump their state. Marking their parent
+ relation is not enough for this purpose.
+