Re: Tablespace patch review

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