From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Philip J(dot) Warner" <pjw(at)rhyme(dot)com(dot)au> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Subject: | Re: Big 7.1 open items |
Date: | 2000-06-22 20:11:56 |
Message-ID: | 200006222011.QAA12816@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> pg_dump is a good basis for any pg_backup utility; perhaps as you indicated
> elsewhere, more carefull formatting of the dump files would make
> table-based restoration possible. In another response, I also suggested
> allowing overrides of placement information in a restore operation- the
> simplest approach would be an 'ignore-storage-parameters' flag. Does this
> sound reasonable? If so, then discussion of file-id based on OID needs not
> be too concerned about how db restoration is done.
My idea was to make dumping of tablespace locations/symlinks optional.
By trying to control it on the load end, you have to basically have some
way of telling the backend to ignore the symlinks on load. Right now,
pg_dump just creates SQL commands and COPY commands.
--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2000-06-22 20:17:48 | Interesting mention of PostgreSQL in news |
Previous Message | The Hermit Hacker | 2000-06-22 18:54:17 | Re: Thoughts on multiple simultaneous code page support |
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2000-06-22 22:05:38 | Re: Big 7.1 open items |
Previous Message | Denis Perchine | 2000-06-22 15:40:40 | Re: Re: [GENERAL] libpq error codes |