The original post is clearly referring to the general engineering usage of rollback, as seen, for example, in source code control systems. As I pointed out before, 'rollback' is defined by its effects, not the mechanism by which it is performed, to which I might add that it is even less defined by mechanisms that are specific to a particular implementation.

If the existence of a record of the rolled-back transaction made a difference to whether an action is a rollback or not, then, by your argument, it would seem that the existence, or not, of a backup (or any other record) preserving the prior state of the system, would make the difference as to whether an SQL rollback was or was not actually a rollback. This, of course, is absurd, but its what you get from mistaking an implementation for a definition.

> In any case it seems fairly useless to debate what the meaning of "rollback" should be.

That was the point of my first post in this thread (with special reference to self-serving definitions.)