Tom Lane wrote: > Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers