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
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 |