I wrote the pg_dump bits, so I guess I can answer these...
> And about restore, particularly to another machine, what do we do if the
> tablespace can't be created in the location specified in the dump? The
> tablespace creation fails, and all objects specified in that tablespace
> also fail? Seems bad, particularly if you are restoring after a
> hardware failure. Do we need a GUC that says "if the tablespace doesn't
> exist, create the object in the default location?" Do we need a
> pg_dump option that ignores tablespaces completely for portability and
> for restoring to another server?
Weeeell. There's a lot of stuff that can already fail in a restore -
you always must watch your restore output to ensure things have worked.
When I restore and it can't create a tsearch function because I forgot
to install the tsearch.so, it errors and then keeps going with tables
and triggers and all sorts of stuff failing to restore because they
depended on that function. I don't see the failure to create a
tablespace as being any different.
> Is pg_dump smart enough not to emit the tablespace if the object would
> already be created in the right tablespace, perhaps because of its
> schema?
Yes it is, I was very careful about that. If you never use a tablespace
in your life, you will never see tablespace commands in your dumps. The
changes to pg_dump work just fine against a pre-7.5 backend and again no
tablespace commands will be output.
> The new tablespace clause adds a non-standard clause to CREATE
> TABLE, something we were hoping to avoid, but I doubt it is possible.
Well, if you don't use them, you won't see them, so I don't have a
problem with that :)
> Do we need ALTER TABLESPACE to move tablespaces, and ALTER clauses to
> move objects to other tablespaces? Are these TODO items for later?
Would be nice :) I'm also in favour of "ADD [PRIMARY KEY | UNIQUE
](blah) TABLESPACE asdf" which isn't in the current patch.
Chris