
Hello,

I think I have found a feature of pg_restore that may be a bug.

If the --clean option AND --dbname=database option are used with an
initially empty database, the restoration fails, although the very same
options with a "| psql database" works fine.

The internal psql with --dbname option fails at the generated clean
stuff if the database is empty, as the ALTER and DROP tables are
reported to fail and the generation is stopped. In the piped version,
these initial errors are ignored.

sh> createdb comics
sh> pg_restore --clean --no-owner --no-acl --dbname=comics comics.dbz
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "public.a_ecrit" does not exist

However it works fine without the "--clean" option.

It seems that the instruction that fails is :
ALTER TABLE ONLY public.a_ecrit DROP CONSTRAINT "$2";

It would make sense to ignore some alter/drop errors in pg_restore.

-- 
Fabien Coelho - coelho@cri.ensmp.fr

Mon, 2 Feb 2004 16:44:55 +0100 (CET)
Fabien COELHO <coelho@cri.ensmp.fr>
pg_restore bug in 7.4.1 ?
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> It would make sense to ignore some alter/drop errors in pg_restore.

For the most part I think pg_restore should ignore *all* SQL errors and
try to keep plugging.  This would more nearly emulate the behavior of
pg_dump SQL scripts, which is the older and better-tested means of
restoring stuff.  There's no downside that I can see --- if the restored
database is too screwed up to use, you can drop it and try again.

This issue has been on the radar screen for awhile, but no one has
gotten around to making it happen...

			regards, tom lane

Mon, 02 Feb 2004 12:32:05 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_restore bug in 7.4.1 ? 

> Fabien COELHO <coelho@cri.ensmp.fr> writes:
> > It would make sense to ignore some alter/drop errors in pg_restore.
>
> [...]
>
> This issue has been on the radar screen for awhile, but no one has
> gotten around to making it happen...

Maybe it could be appended to the "todo" list, so as not to be too far
away from sight. Otherwise the sonar will find it again...

-- 
Fabien Coelho - coelho@cri.ensmp.fr

Tue, 3 Feb 2004 15:06:43 +0100 (CET)
Fabien COELHO <coelho@cri.ensmp.fr>
Re: pg_restore bug in 7.4.1 ? 
Fabien COELHO wrote:
> 
> > Fabien COELHO <coelho@cri.ensmp.fr> writes:
> > > It would make sense to ignore some alter/drop errors in pg_restore.
> >
> > [...]
> >
> > This issue has been on the radar screen for awhile, but no one has
> > gotten around to making it happen...
> 
> Maybe it could be appended to the "todo" list, so as not to be too far
> away from sight. Otherwise the sonar will find it again...

If people want this, can I get some wording?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 3 Feb 2004 11:32:38 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: pg_restore bug in 7.4.1 ?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> If people want this, can I get some wording?

* Make pg_restore continue after errors, so it acts more like pg_dump scripts

			regards, tom lane

Tue, 03 Feb 2004 11:49:37 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: pg_restore bug in 7.4.1 ? 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > If people want this, can I get some wording?
> 
> * Make pg_restore continue after errors, so it acts more like pg_dump scripts

Added.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 3 Feb 2004 11:51:36 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: pg_restore bug in 7.4.1 ?