Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I am confused. I thought Tom's argument was that we shouldn't add an > > overly complex tablespace SET variable just to prevent the non-standard > > TABLESPACE in CREATE, which I can understand. However, the text above > > seems to indicate we don't need an 'ignore tablespace specification if > > it does not exist' which I think we do need for cases where we want to > > restore on to a system that doesn't use tablespaces or for > > non-super-user restores. > > I'm willing to live with a "soft error" type of GUC variable for those > cases. 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. (Which would be consistent > with the way we handle selection of which schema to create in, so I'm > not necessarily against it.) I guess what I'm trying to say is I don't > want a hodgepodge design, because I think it'll be confusing and > unusable.
Agreed. My tablespace path idea would be very hard to understand if combined with the existing db/schema/table default rules. I can't decide which is the best approach. Don't indexes default to the schema of the table rather than the schema path, so they aren't 100% controlled by the search path? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
