Re: Using ALTER TABLESPACE in pg_dump

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using ALTER TABLESPACE in pg_dump
Date: 2004-10-25 14:28:26
Message-ID: 200410251428.i9PESQ929475@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Philip Warner wrote:
> If we can adopt the move-after-create solution, then we really only have
> two options:
>
> - virtual tablespaces (which do seem kind of useful, especially for
> development vs. production config where the local/personal dev version
> can use the same script as a production DB but not need half a dozen TSs)
>
> - magic-tablespace-var that behaves like the schema search path

I was thinking we could have a var like schema search path that
specifies where we try to create the object:

SET tablespace_path = 'tblspc1, pg_default';
CREATE TABLE test(x int);

This combines the idea of pulling the TABLESPACE specification out of
the CREATE, and allows a fallback if the primary tablespace doesn't
exist.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-10-25 14:34:07 Re: Using ALTER TABLESPACE in pg_dump
Previous Message Karel Zak 2004-10-25 13:30:22 Re: to_char/to_number loses sign