Tom Lane wrote:
> Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> > 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.
>
> I think this would be fairly pointless. In most of the practical
> tablespace scenarios I can think of, the tablespace directory probably
> lives within a root-owned directory (eg, a filesystem root directory).
> That's why CREATE TABLESPACE expects the directory to have been made
> already.
>
> In point of fact I think this discussion is much ado about nothing,
> as there is already a workaround that is about as simple as anything
> that we would likely be able to substitute. Suppose the dump contains
> "CREATE TABLESPACE t1 LOCATION '/foo/bar'" and for some reason /foo/bar
> is no longer an appropriate location. All the DBA need do is select
> a location that *is* suitable and create tablespace t1 at that location.
> Then run the restore. The create tablespace command will fail on
> duplicate name, but the tablespace is there and all the subsequent
> operations will be just fine.
>
> Of course we need to document this procedure, but we'd have to document
> any other approach as well...
OK, but is the DBA going to be able to easily find the tablespaces the
dump uses?
--
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