Dear Tom,
>> [...]
>> This combines the idea of pulling the TABLESPACE specification out of
>> the CREATE, and allows a fallback if the primary tablespace doesn't
>> exist.
>
> ... and takes us even further away from the notion that the default
> tablespace is determined by the parent object (database or schema).
>
> I think that we have a clean, understandable, easy-to-use tablespace
> behavior now, and we should not muck it up for abstract second-order
> goals like having portable dumps for databases that were created
> unportably in the first place.
I disagree on the view that being able to restore a database on another
machine after a crash is an "abstract second-order goal";-)
ISTM that the core business of a database is to help organize and protect
data, and it is plainly that. You just wish you won't need it, so it is
somehow "abstract", but when and if you need it, it is not "second-order"
at all;-) and it is much too late to redo the dump.
When a machine crashes, usually I did not foresee how it will crash, and
whether I will or will not be able to restore on the same machine, with or
without the same tablespaces... It depends on what went wrong.
Thus ISTM that having the ability to fix that at restore time is simply
what is needed, when it is needed.
Now I do agree that having a straight behavior is a much better thing.
The "ALTER ... TABLESPACE ..." generated by restore from some headers
seems the right simple solution to me, but the alter syntax is not fully
implemented AFAICR:-(
Completing the implementation for the missing parts (ALTER DATABASE... and
ALTER SCHEMA... ?), feature/beta freeze or not, would seem the reasonnable
path to me.
I'm sorry I don't have time to develop and submit a patch...
Have a nice day,
--
Fabien Coelho - coelho@cri.ensmp.fr