Re: Rearranging ALTER TABLE to avoid multi-operations bugs

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2019-Oct-29, Tom Lane wrote:
>> The thing I think you are actually worried about is the interaction
>> with event triggers, which is already a pretty horrid mess in this
>> code today. I don't really follow the comment here about
>> "ordering of queued commands". It looks like that comment dates to
>> Alvaro's commit b488c580a ... can either of you elucidate that?

> The point of that comment is that if you enqueue the commands as they
> are returned by pg_event_trigger_ddl_commands() (say by writing them to
> a table) they must be emitted in an order that allows them to be
> re-executed in a remote server that duplicates this one, and the final
> state should be "the same".

Hm. I don't think I understand what is the use-case behind all this.
If "ALTER TABLE tab DO SOMETHING" generates some subcommands to do what
it's supposed to do, and then an event trigger is interested in replaying
that ALTER, how is it supposed to avoid having the subcommands happen
twice? That is, it seems like we'd be better off to suppress the
generated subcommands from the event stream, because they'd just get
generated again anyway from execution of the primary command. Or, if
there's something that is interested in knowing that those subcommands
happened, that's fine, but they'd better be marked somehow as informative
rather than something you want to explicitly replay. (And if they are
just informative, why is the ordering so critical?)

regards, tom lane