Skip site navigation (1) Skip section navigation (2)

Re: Big 7.1 open items

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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                        |
  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

In response to

pgsql-hackers by date

Next:From: Lamar OwenDate: 2000-06-22 20:17:48
Subject: Interesting mention of PostgreSQL in news
Previous:From: The Hermit HackerDate: 2000-06-22 18:54:17
Subject: Re: Thoughts on multiple simultaneous code page support

pgsql-patches by date

Next:From: The Hermit HackerDate: 2000-06-22 22:05:38
Subject: Re: Big 7.1 open items
Previous:From: Denis PerchineDate: 2000-06-22 15:40:40
Subject: Re: Re: [GENERAL] libpq error codes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group