Tom Lane wrote: > Robert Treat <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
