Re: Storage Location / Tablespaces (try 3)
От | Jim Buttafuoco |
---|---|
Тема | Re: Storage Location / Tablespaces (try 3) |
Дата | |
Msg-id | 20020307160519.M90856@buttafuoco.net обсуждение исходный текст |
Ответ на | Re: Storage Location / Tablespaces (try 3) ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>) |
Ответы |
Re: Storage Location / Tablespaces (try 3)
|
Список | pgsql-hackers |
Andreas, My first try passed the tablespace OID arround but someone pointed out the the WAL code doesn't know what the tablespace OID is or what it's location is. This is why I would like to use the symbolic links. Tom do you have any ideas on this? Jim > > (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 по дате отправления: