Sorry Tom, I forgot to include pgsql-bugs in the email list...
Hi Tom,
Thanks for your answer.
Tom Lane a =E9crit :
> phb.emaj@free.fr writes:
>=20=20=20
>> When a table is registered as an extension configuration table and conta=
ins
>> a serial column, the current value of the sequence associated to this se=
rial
>> column is not dumped by pg_dump.
>>=20=20=20=20=20
>
> I think the way to make that happen is to also register the sequence as
> a configuration table of the extension. It's not clear to me that that
> should happen by default; it would depend a lot on how the extension
> designer intends to manage modifications of the table.
>=20=20=20
OK, there may be cases when one doesn't want to restore the associated=20
sequence value.
In such a case:
- either a function allows to register the serial sequence as a=20
configuration table (your proposal),
- or the serial sequence is implicitely considered as a configuration=20
table, which would me more natural (see discussion for BUG #6683), and=20
another function allows to removes this state.
Anyway, (and this is not strictly related to this bug report) there is a=20
need:
- for registering an independant sequence of an extension as "to be=20
pg_dumped/restored", and
- for unregistering a table and sequence that has been previously=20
processed by pg_extension_config_dump (unless I miss the way to do this).
>> echo "--> And sequences cannot be registered as 'content to be dumped'"
>> $PGBIN/psql -ac "select
>> pg_catalog.pg_extension_config_dump('tbl1_col1_seq','');"
>>=20=20=20=20=20
>
> This test proves nothing of the kind. Please read the error message:
> ERROR: pg_extension_config_dump() can only be called from an SQL script =
executed by CREATE EXTENSION
> You have to do it in the extension's script.
>=20=20=20
You are right. My intent here was just to show that feeding the=20
pg_extension_config_dump function with the sequence name is not a=20
solution, ... in the current version at least.
Regards.
Philippe BEAUDOIN.