Re: Using ALTER TABLESPACE in pg_dump

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I am confused.  I thought Tom's argument was that we shouldn't add an
> > overly complex tablespace SET variable just to prevent the non-standard
> > TABLESPACE in CREATE, which I can understand.  However, the text above
> > seems to indicate we don't need an 'ignore tablespace specification if
> > it does not exist' which I think we do need for cases where we want to
> > restore on to a system that doesn't use tablespaces or for
> > non-super-user restores.
> 
> I'm willing to live with a "soft error" type of GUC variable for those
> cases.  I don't want a GUC variable that actively changes the default
> tablespace; at least not unless you want to abandon the current
> mechanisms for default tablespace choices entirely, and go over to
> making the GUC variable be the sole arbiter.  (Which would be consistent
> with the way we handle selection of which schema to create in, so I'm
> not necessarily against it.)  I guess what I'm trying to say is I don't
> want a hodgepodge design, because I think it'll be confusing and
> unusable.

Agreed.  My tablespace path idea would be very hard to understand if
combined with the existing db/schema/table default rules.  I can't
decide which is the best approach.  Don't indexes default to the schema
of the table rather than the schema path, so they aren't 100% controlled
by the search path?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073