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/personal dev 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 |/

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 13 of 45 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedOct 18, '04 at 4:27p
activeNov 6, '04 at 7:37p
posts45
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase