Re: Using ALTER TABLESPACE in pg_dump - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Using ALTER TABLESPACE in pg_dump
Date
Msg-id 200410292045.i9TKj2V09888@candle.pha.pa.us
Whole thread Raw
In response to Re: Using ALTER TABLESPACE in pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Added to open items list:

* Tablespace       o add new GUC default_tablespace to control object creation when         no explicit TABLESPACE
clauseexists
 
         Use it in pg_dump.
       o Remove tablespace default for databases and schemas
         Place objects as specified by the TABLESPACE clause or         default_tablespace.  The database tablespace
controlsonly         the system objects.
 



---------------------------------------------------------------------------

Tom Lane wrote:
> Philip Warner <pjw@rhyme.com.au> writes:
> > At 08:00 AM 26/10/2004, Tom Lane wrote:
> >> I don't want a GUC variable that actively changes the default
> >> tablespace; at least not unless you want to abandon the current
> >> mechanisms for default tablespace choices entirely, and go over to
> >> making the GUC variable be the sole arbiter.
> 
> > Something consistent with Schemas does sound good to me; a tablespace 
> > search path (or just single default), and support for a TABLESPACE clause 
> > on table and INDEX definitions would be good.
> 
> I can't see what a search path would be good for.
> 
> > For the three largest databases I work on, the namespace/schema that a 
> > table resides in is irrelevant to the tablespace that it should be stored 
> > in. So default tablespaces on the schema are a bit of a pointless feature. 
> > The ability to have the features of schemas: default tablespace for given 
> > users, a GUC variable, and ACLs on tablespaces would be far more valuable.
> 
> Another nice thing is that not having default tablespaces associated
> with schemas eliminates that nasty issue about being able to drop such a
> tablespace while the schema is still there.
> 
> It seems like we still need some notion of a database's schema, to put
> the system catalogs in, but perhaps that need not be the same as the
> default schema for user tables created in the database?
> 
> I'd be willing to jump this way if we can work out the
> default-tablespace inconsistencies that Bruce has on the open items
> list.  Does anyone want to draft a concrete proposal?  It seems like the
> basic elements are:
> 
>     * A GUC variable named something like default_tablespace that
>     controls which TS objects are created in when there's
>     no explicit TABLESPACE clause.  The factory default for this
>     would of course be pg_default.  Otherwise it's settable just
>     like any other GUC var.
> 
>     * Get rid of TABLESPACE clause for CREATE SCHEMA, and
>     pg_namespace.nsptablespace (ooops, another initdb).
> 
>     * Need to define exactly what TABLESPACE clause for a database
>     controls; location of its catalogs of course, but anything else?
> 
>     * We could possibly say that a TABLESPACE clause attached to
>     CREATE TABLE determines the default tablespace for indexes
>     created by the same command; I'm not sure if this is a good
>     idea, or if the indexes should go into default_tablespace
>     absent a TABLESPACE clause attached directly to their defining
>     constraints.  We certainly want default_tablespace to control
>     indexes created by separate commands, so there'd be some
>     inconsistency if we do the former.
> 
>             regards, tom lane
> 

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [pgsql-hackers-win32] Win32 open items
Next
From: Tom Lane
Date:
Subject: Re: [NOVICE] Postgresql crash- any ideas?