Robert Treat wrote:
> On Wednesday 18 August 2004 21:39, you wrote:
> > Christopher Kings-Lynne wrote:
> > > > It is a little bit different because a schema, a table or a function
> > > > are database application issues and are normally addressed by pg_dump
> > > > and pg_restore, although tablespaces are more an administration issue
> > > > wrt disk layout and the like, which are likely to be different from one
> > > > machine to another (compare with I obviously want the same
> > > > schema/table/function for my application). So the notion of
> > > > dump/restore of a tablespace need some careful thinking.
> > > >
> > > > But maybe I'm just stupid to dream that I could restore or transfer my
> > > > data even if I used a tablespace somewhere? ;-)
> > >
> > > OK, perhaps. It it not easy to implement however, since the tablespace
> > > clause on indexes comes from the pg_get_indexdef() function and isn't
> > > added by pg_dump.
> > >
> > > Bruce - pg_dump TODO for --no-tablespace or something?
> >
> > Uh, TODO already has:
> >
> > * Allow database recovery where tablespaces can't be created
> >
> > When a pg_dump is restored, all tablespaces will attempt to be created
> > in their original locations. If this fails, the user must be able to
> > adjust the restore process.
>
> If the location doesn't exist will postgresql try to create it? istm it could
> do this and if it fails then you are no worse off, but if it were to succeed
> you're that much better off.
Yea, I assume if you can't create the tablespace you put everything for
that tablespace in the default tablespace.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073