All,
* Stephen Frost (sfrost@snowman.net) wrote:
> * 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 ...
Any further thoughts on this? I haven't tried to go implement anything
yet but I'm definitely concerned that we may run into a keyword issue
with ALTER TABLE, but I don't really want to add 'TABLES' either.
Anyone have any other suggestions or ideas?
Thanks,
Stephen
