Re: Open Items

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: Open Items
Дата
Msg-id Pine.LNX.4.61.0410181331480.3419@sablons.cri.ensmp.fr
обсуждение исходный текст
Ответ на Re: Open Items  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Open Items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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
aftera crash) of data    to another base which would not have these tablespaces. If the disk    is crashed, I cannot
redothe 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
tostore 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@cri.ensmp.fr


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jeroen T. Vermeulen"
Дата:
Сообщение: Re: additional GCC warnings
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Open Items