Re: Open Items

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

In response to

Responses

Browse pgsql-hackers by date

  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