Re: Storage Location / Tablespaces (try 3) - Mailing list pgsql-hackers

From Jim Buttafuoco
Subject Re: Storage Location / Tablespaces (try 3)
Date
Msg-id 20020307160519.M90856@buttafuoco.net
Whole thread Raw
In response to Re: Storage Location / Tablespaces (try 3)  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Responses Re: Storage Location / Tablespaces (try 3)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: date formatting and tab-complete patch
Next
From: Jan Wieck
Date:
Subject: Re: a vacuum thread is not the answer