On Mon, Jun 23, 2014 at 05:10:02PM -0400, Stephen Frost wrote:
> * Stephen Frost (sfrost@snowman.net) wrote:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > 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?
I recommend:
SELECT tablespace_move(old_tablespace name, new_tablespace name); SELECT tablespace_move(old_tablespace name,
new_tablespacename, relkind "char");
Concerning the problem that started this thread, I would raise one ALTER TABLE
event per table and not fire an event for the bulk request as a whole.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
