* Tom Lane (t...@sss.pgh.pa.us) wrote: > Alvaro Herrera <alvhe...@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
signature.asc
Description: Digital signature
