Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> The problem in this particular case is that TABLESPACE is a "global"
> object, thus not supported; but ALTER TABLESPACE MOVE is a command that
> modifies tables (which *are* supported), not tablespaces.
> 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
MOVE ALL [ TABLES | INDEXES | ... ] IN TABLESPACE foo TO bar
wouldn't be less confusing. Not sure what we'd use as command tag
for it though (not MOVE, since that's taken).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
