Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE
От | Bruce Momjian |
---|---|
Тема | Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE |
Дата | |
Msg-id | 200408231409.i7NE9X809863@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] ALTER SCHEMA ... SET TABLESPACE (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: