Re: pg_restore cannot restore an index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Jie Liang <jie(at)stbernard(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: pg_restore cannot restore an index
Date: 2003-01-16 18:34:17
Message-ID: 26074.1042742057@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Yes, I remember this. The code in 7.3 looks OK to me. Can you show me a
> command line that fails for you?

It does in fact work for me --- if the object in question is recorded as
an INDEX in the dump. These days, lots of things get recorded as
CONSTRAINTs instead. For example, given

create table t1 (f1 int primary key);
create table t2 (f1 int primary key);
create table foo(f1 int);
create index fooey on foo(f1);

I get a dump that has a TOC like

$ pg_restore -l z.dump
...
2; 149798 TABLE t1 postgres
3; 149802 TABLE t2 postgres
4; 149806 TABLE foo postgres
8; 149798 TABLE DATA t1 postgres
9; 149802 TABLE DATA t2 postgres
10; 149806 TABLE DATA foo postgres
7; 149808 INDEX fooey postgres
5; 149800 CONSTRAINT t1_pkey postgres
6; 149804 CONSTRAINT t2_pkey postgres

and the -I option will find "fooey", but not "t1_pkey" or "t2_pkey".

Perhaps the gripe is really that we need a "restore specific constraint"
option? If so, should we overload -I or invent a separate switch?

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Jie Liang 2003-01-16 22:21:43 Re: pg_restore cannot restore an index
Previous Message Bruce Momjian 2003-01-16 18:07:21 Re: pg_restore cannot restore an index