From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brian Dimeler <briand(at)lserve(dot)com> |
Cc: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: sequences not restoring properly |
Date: | 2006-01-20 18:38:11 |
Message-ID: | 25843.1137782291@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Brian Dimeler <briand(at)lserve(dot)com> writes:
> In the database dump however, this default is omitted (and consequently, when restoring, the new
> server creates an implicit sequence named 'bands_dbbandcode_seq' instead of the correct
> bands_dbcode_seq, and it is never set to the correct value).
> This happens for a few other tables too; basically anything that had its serial columns or tables
> renamed at some point doesn't get its sequences re-created.
Oh, they're created all right. But they're created according to what
the name ought to be now given the new column name, and the setval()
commands in the old dump are wrong for that.
Per Doug's response, use the 8.1 pg_dump if you can, as it knows how to
generate setval() calls that can deal with this effect. There's no
very good solution for it in 7.4 unfortunately --- if you want to use
the old pg_dump, you have to do the setvals by hand after loading the
dump.
Note that you'd have the same problem trying to reload that dump into
7.4 ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-20 18:40:06 | Re: What is the maximum length of an IN(a, b, c....d) list in PostgreSQL |
Previous Message | Brian Dimeler | 2006-01-20 18:36:39 | Re: sequences not restoring properly |