From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Net Virtual Mailing Lists" <mailinglists(at)net-virtual(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pgdump of schema... |
Date: | 2004-11-24 16:05:14 |
Message-ID: | 9682.1101312314@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Net Virtual Mailing Lists" <mailinglists(at)net-virtual(dot)com> writes:
> When I do a "pgdump --schema=someschema somedatabase > something.dump",
> the results of the dump file look like this:
> CREATE TABLE emailtemplates (
> email_template_id integer DEFAULT
> nextval('"emailtemplate_email_templat_seq"'::text) NOT NULL,
Hmm. What you've apparently got here is a serial column that you've
carried forward from an old (pre 7.3 at least) database. Had the serial
default been created in 7.3 or later then it would be a fully qualified
name (ie nextval('someschema.emailtemplate_email_templat_seq')) and
there would be no issue. For that matter, had the SERIAL column been
created in 7.3 or later, pg_dump would know to say
CREATE TABLE emailtemplates (
email_template_id SERIAL,
...
instead of what it did say. Now it is surely not pg_dump's charter
to editorialize on default expressions that were supplied by the user
(which this was, as far as the current database knows). So this isn't a
pg_dump bug. What it is is a deficiency in the upgrade process that we
had from pre-7.3 to 7.3 databases. You might want to consider running
contrib/adddepend against your database to fix things up. (But note
that it's just a contrib script and is not guaranteed; so keep a prior
dump around ...)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2004-11-24 16:10:53 | Re: PostGreSQL upgrade failed (Debian Packages), need advice... |
Previous Message | Joshua D. Drake | 2004-11-24 16:00:05 | Re: Moving/Using Postgres Binaries on multiple machines |