Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE
Date
Msg-id 200408231409.i7NE9X809863@candle.pha.pa.us
Whole thread Raw
In response to Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Philip Warner <pjw@rhyme.com.au> writes:
> > So, if you do make the changes, will the schema definition be affected by 
> > those changes, or do you expect the tablespace to be embedded in the CREATE 
> > SCHEMA command?
> 
> I thought the idea was for pg_dump to emit something like
> 
>     SET magic_tablespace_variable = some_ts;
> 
>     CREATE TABLE foo (columns...);
> 
> rather than
> 
>     CREATE TABLE foo (columns...) TABLESPACE some_ts;
> 
> the point being no more and no less than this: if "some_ts" doesn't
> exist (or you have other problems like insufficient permissions) then
> the SET command will fail but CREATE TABLE will still succeed, allowing
> the restore to complete in some reasonable fashion.

Right, this would eliminate our non-standard TABLESPACE clause appearing
in pg_dump CREATE TABLEs.

> I am quite unsure why you are pushing this while also insisting that
> we need "die_on_errors" mode for pg_restore.  If you are going to die
> on the first error then these alternatives are equally brittle.

I assume he wants to give users maximum flexibility.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE
Next
From: Oliver Elphick
Date:
Subject: Re: monetary bug