Re: Open Items - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: Open Items
Date
Msg-id Pine.LNX.4.58.0410181045170.19802@linuxworld.com.au
Whole thread Raw
In response to Re: Open Items  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Open Items
List pgsql-hackers
On Sun, 17 Oct 2004, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >     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 feel the same way for more or less the reasons you outline.

> 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.

That's a useful feature but I'm not sure it solves the problem people
originally put (to me at least). User has data in a tablespace on a
seperate device. The device crashes fatally and the user needs to restore
the database. All the user's dumps contain tablespace clauses because the
user did not anticipate the device dying. This, I think, is why people
wanted to either ignore tablespace clauses, have an override or something
else.

I still think, however, that a workable solution is to bring up a new
system, create the tablespaces on some online partition, and pg_restore
the dump. pg_dump does not dump CREATE TABLESPACE so we wont encounter
problems there.

Have I missed something there? (Highly likely as I am still pre-coffee).

Gavin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Open Items
Next
From: Neil Conway
Date:
Subject: Re: spinlocks: generalizing "non-locking test"