All,
This is exactly what my patch added. The ability to do the following
CREATE DATABASE foo TABLESPACE X INDEX_TABLESPACE Y TEMP_TABLESPACE Z;
CREATE SCHEMA foo TABLESPACE X INDEX_TABLESPACE Y TEMP_TABLESPACE Z; -- override the database setting
CREATE TABLE T (...) TABLESPACE X; -- override the SCHEMA setting
CREATE INDEX I (...) TABLESPACE X; -- override the SCHEMA setting
CREATE TABLESPACE A location '/XXX/YYY/ZZZ'; -- define a tablespace
If any of the TABLESPACE options are missing take from DATABASE/SCHEMA setting.
I don't remember exactly why it was rejected at the time.
Jim
> hi
>
> Dnia wto 28. stycznia 2003 16:19, Tom Lane napisa³:
> >
> > Well, what I envision is only a cleaner reimplementation of the
> > existing LOCATION facility: the DBA will be able to designate certain
> > directories as tablespaces and then assign individual tables, indexes,
> > etc to particular tablespaces. Presumably, the DBA places each
> > tablespace directory on a different disk (otherwise there's not much
> > point in the exercise), and then the arrangement lets him control what
> > lives where.
> >
>
> Does this mean (in long term) ability to:
>
> CREATE SCHEMA xyz
> DEFAULT TABLESPACE ts_data
> INDEX TABLESPACE ts_index;
> (to define place for created objects)
>
> or
>
> ALTER TABLE tab1 TABLESPACE ts_data1;
> (to change location of datafile for 'tab1')
>
> ?
>
> --
>
> Mariusz Czulada
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html