Re: Using ALTER TABLESPACE in pg_dump - Mailing list pgsql-hackers

From Philip Warner
Subject Re: Using ALTER TABLESPACE in pg_dump
Date
Msg-id 6.1.2.0.0.20041025131741.04783450@203.8.195.10
Whole thread Raw
In response to Re: Using ALTER TABLESPACE in pg_dump  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Using ALTER TABLESPACE in pg_dump
List pgsql-hackers
At 12:38 PM 25/10/2004, Bruce Momjian wrote:

>         o  Anything that works only for pg_restore and hence doesn't
>            work for ASCII dumps isn't an acceptable solution

Agree; but don't forget that an ascii dump is implemented almost 
identically to "pg_dump | pg_restore", so when I refer to using pg_restore 
in this thread it almost certainly applies to ascii dumps as well. Eg. 
extra stuff in the TOC, and using the definition as a template *will* 
produce the requested output in ascii dumps.


>         o  Creating the tablespaces before the dump is restored is
>            a good solution for moving tablespaces, but as Tom pointed
>            out, it doesn't work well for non-super-user restores

And for users who want to create a single database with no extra 
tablespaces (eg. development version vs. production instance).


>         o  Moving the indexes can't be dont easily after they are
>            created because they are not zero-length files

Pity.


>         o  The soft-failure GUC option for non-existant tablespaces
>            is a hack just for use by pg_dump.  It doesn't fix the
>            problem that the tablespace clause makes the SQL nonstandard.

If we can adopt the move-after-create solution, then we really only have 
two options:
 - virtual tablespaces (which do seem kind of useful, especially for   development vs. production config where the
local/personaldev version   can use the same script as a production DB but not need half a dozen TSs)
 
 - magic-tablespace-var that behaves like the schema search path

Are there any others?


>And the best quote from the thread:
>
>Philip Warner wrote:
> > <soapbox>
> > A fact I positively loath! Relying on the 'bluder-on-regardless' approach
> > is not something I'd like to enshrine.
> > </soapbox>
>
>The 'bluder-on-regardless' phrase is very funny.


Fame at last! Even with the typo.




----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 03 5330 3172          |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                 |    --________--
PGP key available upon request,  |  /
and from pgp.mit.edu:11371       |/ 



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: gettext calls in pgport
Next
From: Tatsuo Ishii
Date:
Subject: Re: Proposed Query Planner TODO items