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 <[EMAIL PROTECTED]> wrote:
I wrote:
> "Michael Nolan" <[EMAIL PROTECTED]> 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
