Skip site navigation (1) Skip section navigation (2)

Re: Using ALTER TABLESPACE in pg_dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>,Philip Warner <pjw(at)rhyme(dot)com(dot)au>,Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using ALTER TABLESPACE in pg_dump
Date: 2004-10-25 22:00:42
Message-ID: 1579.1098741642@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-10-25 22:13:54
Subject: Re: Using ALTER TABLESPACE in pg_dump
Previous:From: CSNDate: 2004-10-25 21:56:34
Subject: Re: copy - fields enclosed by, ignore x lines

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group