Re: Storage Location / Tablespaces (try 3)

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB SD
Тема Re: Storage Location / Tablespaces (try 3)
Дата
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA4961D67@m0114.s-mxs.net
обсуждение исходный текст
Ответ на Storage Location / Tablespaces (try 3)  ("Jim Buttafuoco" <jim@buttafuoco.net>)
Ответы Re: Storage Location / Tablespaces (try 3)  ("Jim Buttafuoco" <jim@buttafuoco.net>)
Список pgsql-hackers
> (If people like TABLESPACE instead of LOCATION then
> s/LOCATION/TABLESPACE/g
> below)

I like "tablespace" :-)

> This patch would add the following NEW commands
> ----------------------------------------------------
>     CREATE LOCATION name PATH 'dbpath';
>     DROP   LOCATION name;

> The following command syntax would be modified
> ------------------------------------------------------
> CREATE DATABASE WITH DATA_LOCATION=XXX INDEX_LOCATION=YYY
> TEMP_LOCATION=ZZZ
> CREATE TABLE aaa (...) WITH LOCATION=XXX;
> CREATE TABLE bbb (c1 text primary key location CCC) WITH LOCATION=XXX;
> CREATE TABLE ccc (c2 text unique location CCC) WITH LOCATION=XXX;
> CREATE INDEX XXX on SAMPLE (C2) WITH LOCATION BBB;

Sounds great, but shouldn't we use syntax that is already around,
like Oracle's or DB2's or ...

> The symbolic links will enable the rest of the software to be location
> independent.

I see, that this is the least intrusive way, but I am not sure this is the
best way to do it. It would probably be better to pass the Tablespace oid
around (or look it up).

That would also leave the door open for other "Tablespace types" (currently
"Filesystem directory" an OS managed tablespace :-).

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Karel Zak
Дата:
Сообщение: Re: date formatting and tab-complete patch
Следующее
От:
Дата:
Сообщение: Re: Postgresql backend to perform vacuum automatically