It seems to me that the logical way to do this would be that when the underlying table is dumped the sequence is dumped with it, like indexes are. Otherwise if the table is restored from the dump file the sequence may be out of sync, or not present at all.
What happens when dumping a table with foreign key constraints?
Dumping the sequence separately should also be permissable, but possibly with some kind of warning note in the dump output that the sequence is linked to a data field.
--
Mike Nolan
On 4/15/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: I wrote:
> "Michael Nolan" <htfoot@gmail.com> writes:
>> I've narrowed down the conditions under which pg_dump in 8.2.3 is creating a
>> segmentation fault.
>> It appears to happen only when dumping a sequence that is created for a
>> serial data element.
> Thanks for the test case --- I can reproduce this now on 8.2 and HEAD too.
> Will take a look tomorrow if no one beats me to it.
The failure occurs while trying to emit an ALTER SEQUENCE OWNED BY
command to link the sequence to its owning serial column. If we chose
not to dump the parent table then we won't have collected enough
information about it to create this command (specifically, we never
fetched its column names).
The definitional question is: if we selected only the sequence to dump,
do we want that ALTER command to appear in the output or not? It's a
reasonably straightforward fix either way (a bit easier for "not"),
but I'm unsure which is the most useful behavior.
regards, tom lane