Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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 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
