On Mon, Jun 23, 2014 at 05:10:02PM -0400, Stephen Frost wrote: > * Stephen Frost (sfr...@snowman.net) wrote: > > * Tom Lane (t...@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_tablespace name, 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers