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

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.


---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend

Reply via email to