Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > The ALTER TABLESPACE MOVE command affects tables, not tablespaces; and
> > as such, I think event triggers should support that command. I'm not
> > proposing to change event triggers at this stage, but since IMO we will
> > want to do that in 9.5, we need it to have a different command tag than
> > plain ALTER TABLESPACE. This is so that check_ddl_tag() can compare
> > the tag with ALTER TABLESPACE and say "unsupported", and ALTER
> > TABLESPACE MOVE and say "supported". Both are currently spelled the
> > same, which will be a problem.
>
> > Therefore I propose the attached patch for 9.4.
>
> Hm. While the specific change here seems harmless enough, the argument
> for it seems to me to indicate that the very design is broken. Do you
> expect event triggers to distinguish all the different subflavors of
> ALTER TABLE, for example, on the basis of the command tag? Backwards
> compatibility is going to prevent us from refining the tag strings
> that much.
Actually, I don't -- I have already implemented ALTER TABLE for event
triggers, and there wasn't any need to tweak the command tags there.
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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
