From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Open Items |
Date: | 2004-10-18 11:58:31 |
Message-ID: | Pine.LNX.4.61.0410181331480.3419@sablons.cri.ensmp.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear Tom,
>> o remove non-portable TABLESPACE clause from CREATE TABLE and
>> use a new default_tablespace SET variable
>
> I'm coming around to the conclusion that this is simply a bad idea.
I agree that the "set" approach is error prone.
Another idea was to issue an "ALTER" after the CREATE.
That would move the empty table from one tablespace to another, at small
cost. If it fails, it is simply ignored by the restoration process,
but the table was already created so it exists.
> What we might want to do is invent a --notablespace option for pg_dump,
> comparable to --noowner, to let someone make a dump that contains no
> TABLESPACE clauses.
(1) --notablespace would be useful, but it would not fix the problem
I had in mind, i.e. the transfer (possibly after a crash) of data
to another base which would not have these tablespaces. If the disk
is crashed, I cannot redo the pg_dump.
(2) thus it would help to be able to decide this at "restore" time.
I think that one of the implementation idea was to store the
information into some headers.
(3) possible current workaround for the desperate admin:
(a) create fake tablespaces as necessary...
(b) pg_restore ... | sed 's/TABLESPACE .*//' | psql ...
Have a nice day,
--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-10-18 12:04:11 | Re: Open Items |
Previous Message | Jeroen T. Vermeulen | 2004-10-18 11:47:08 | Re: additional GCC warnings |