* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > ALTER TABLESPACE MOVE is a glorified ALTER TABLE. If ALTER TABLESPACE
> > MOVE returned ALTER TABLE as a tag, I think it'd work well too; but not
> > ALTER TABLESPACE. Individually, since the implementation works by
> > calling AlterTableInternal(), it already works.
>
> > Now if you state that the current design in event_triggers that works by
> > slicing CommandTag and comparing the pieces is broken, I don't disagree
> > and I think I have now (in the patch posted in a nearby thread) some
> > more infrastructure to do it differently. But even if we do that, I
> > think we're going to need a way to differentiate ALTER TABLESPACE MOVE
> > from other forms of ALTER TABLESPACE. I haven't given this much
> > thought, though.
>
> Yeah, I'd not paid much attention to it either. Now that I look at it,
> ALTER TABLESPACE MOVE seems like a pretty unfortunate choice of naming
> all around, because (unless I'm misunderstanding) it doesn't actually
> alter any property of the tablespace itself. It might be a bit late
> to propose this, but I wonder if some syntax along the lines of
I'm not against changing it- doing operations on a whole tablespace felt
like it would make sense under 'ALTER TABLESPACE' to me (hence the
implementation) but you're right, it's not actually changing properties
of the tablespaces themselves.
> MOVE ALL [ TABLES | INDEXES | ... ] IN TABLESPACE foo TO bar
I'm not a huge fan of new top-level constructs and re-using MOVE feels
completely wrong to me as that's used for cursors..
> wouldn't be less confusing. Not sure what we'd use as command tag
> for it though (not MOVE, since that's taken).
I would have thought something under ALTER TABLE would make more sense,
if we're going to change it, eg:
ALTER TABLE ALL [ TABLES | INDEXES | ... ] IN TABLESPACE SET TABLESPACE ...
or perhaps something like
ALTER TABLES IN TABLESPACE ...
Thanks,
Stephen
