Bruce Momjian <[EMAIL PROTECTED]> writes:
> One additional idea for this item is to use CREATE to first create the
> object, then move it using ALTER, and the ALTER might fail if the
> tablespace doesn't exist.
This seems fairly impractical, at least for indexes where there is no
way to do the ALTER before the object is filled with data.
> If we add a new SET variable and use it in pg_dump we will have to
> support it forever even if there is no practical use for it.
Yeah, that's one thing that bothers me.
> One interesting side-affect of allowing tablespace specification to fail
> is that it might give users enough control that we can mark this item as
> done:
Hmm, here's a variant idea: how about a GUC variable named something like
"soft_tablespace_specs" which when TRUE would mean that a nonexistent
tablespace name in a TABLESPACE clause is ignored (maybe with a WARNING)
rather than being an error, and so the object is created in whatever the
default tablespace for it would be. You wouldn't even necessarily want
to have pg_dump set this true for itself, but people could turn it on
when they needed to load a dump with wrong tablespace names in it.
(If we didn't have pg_dump turn it on automatically, then we'd not be
beholden to support it forever.)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
