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.20041021104731.06933300@203.8.195.10 Whole thread Raw |
In response to | Re: Using ALTER TABLESPACE in pg_dump (Robert Treat <xzilla@users.sourceforge.net>) |
Responses |
Re: Using ALTER TABLESPACE in pg_dump
|
List | pgsql-hackers |
At 05:41 AM 21/10/2004, Robert Treat wrote: >I've been thinking of an alternative solution that sounds very similar >to this. The idea is to output the CREATE TABLESPACE commands inside >pg_dump.... >... >1) tablespace already exists >to fail, but since we no longer stop on error during restore, <soapbox> A fact I positively loath! Relying on the 'bluder-on-regardless' approach is not something I'd like to enshrine. </soapbox> >2) if you have to restore on a machine with a different disk layout, >give pg_restore a --override-tablespace command, which would substitute >pg_default tablespace into the creation command of any tablespaces that >get passed in. The bonus is that we would only have to parse on one >specific command rather than worry about parsing several different >commands. ... I'm still inclined to avoid any parsing if at all possible. We should hit the code that generates the definitions (90% in pg_dump) and turn the definitions into more intelligent templates. >... I was thinking that you could >create two logical tablespaces on the same physical directory. This is basically the virtual/fake tablespace idea. Sometimes I think it is worth stepping back from a problem and ask what would we do if we had a clean slate, then use that to inform our current set of decisions. I'd be very interested in other people's ideas, but my thinking is: - we might not have a tablespace clause inside object definitions; we could add a STORE TABLE xxx IN TABLESPACE ts statement. Not really practical now; but worth bearing in mind as an approach for future non-standard syntax. - we'd have a full set of ALTER xxx SET TABLESPACE commands which moved relevant data etc. We have most of them. - pg_dump would issue the alter commands after creating the object; OK, it moves files, not very efficient, but using a 'SET MAGIC_TABLESPACE_VAR' has previously been discounted as a solution. *If* you accept this as a good approach in an ideal world, then I think we need to ask ourselves if we should implement the remaining ALTER commands in 8.0 and be done with it. The other solutions: magic-tablespace-var, virtual-tablespaces...all seem to add clunky functionality that will only be used in pg_dump. If we're going to add something, I'd prefer not to add clutter. ---------------------------------------------------------------- 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: