From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Big 7.1 open items |
Date: | 2000-06-22 07:05:00 |
Message-ID: | 7722.961657500@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> writes:
> I'm wondering if pg_dump should store the location of the tablespace. If
> your machine dies, you get a new machine to re-create the database, you
> may not want the tablespace in the same spot. And text-editing a
> gigabyte file would be extremely painful.
Might make sense to store the tablespace setup separately from the bulk
of the data, but certainly you want some way to dump that info in a
restorable form.
I've been thinking lately that the pg_dump shove-it-all-in-one-file
approach doesn't scale anyway. We ought to start thinking about ways
to make the standard dump method store schema separately from bulk
data, for example. That's offtopic for this thread but ought to be
on the TODO list someplace...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-22 07:17:45 | Re: Big 7.1 open items |
Previous Message | Tom Lane | 2000-06-22 06:59:36 | Re: Thoughts on multiple simultaneous code page support |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-06-22 07:17:45 | Re: Big 7.1 open items |
Previous Message | Denis Perchine | 2000-06-22 06:55:27 | Re: libpq error codes |