Re: pgdump of schema...

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

In response to

Responses

Browse pgsql-general by date

  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