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.
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
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.
+