At 06:14 PM 20/08/2004, Fabien COELHO wrote:
>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 DEFAULT
or 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 |/