This prior SET option looks much better and cleaner. Maybe the TOC entry update is not really necessary if the SET is separate?
I'd prefer if it was separate since we want to minimize the number of multi-statement TOC entries...I think. A new TOC entry is close to zero cost. Reformatting the TOC to include the tablespace name is more expensive, but there are a few things I'd like to add, so it's worth it.
If the SET fails, what tablespace is expected to be chose?
Good question. Is there a name for the normal/default/whatever tablespace? Tom may need to implement:
SET DEFAULT TABLESPACE AS FRED
SET DEFAULT TABLESPACE DEFAULTor something less tacky, but allowing for the default to be derived from the schema & database rather than the last SET command. The pg_dump will need to check the result of the SET command and reset the tablespace if it fails...and probably die if that fails.
I can give a hand about the implementation over the week-end, esp. as I'm the one taking a stand on this issue. However I do not know much about pg_dump format and issues, so I'm not sure I'm the best person for a quick and clean implementation.
I'm happy to do the pg_dump changes, assuming Tom gets the SET stuff sorted out. But would appreciate it if you could do some testing.
----------------------------------------------------------------
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 |/
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
