Now, I have my idea on how I'd like the Data Queue / Modification
Triggers to work, but I'm not the one who proposed those two closely
related features. Can the original proposers speak up on what kind of
spec you had in mind?
Since nobody has spoken up about this, I'll spec it myself ...
particularly since I care strongly about it for heterogenous replication
(that is, replication to non-PostgreSQL systems).
As far as I can see, things would be of general utility:
(1) The ability to send asynchronous (or synchronous?) notifications, on
a per-row basis, whenever data is modified *only after commit*. This
has been generally described as "on-commit triggers", but could actually
take a variety of forms.
(2) A generic yet compact portable serialization format for a row of
PostgreSQL data, just as protobuf, or something internal.
(3) A method of marking DDL changes in the data modification stream.
Of the three above, #2 seems the most optional, and possibly completely
counter-productive. Even if we decided that a general portable data
format made sense, we could retrofit it later. So dropping it from the
The question is, can we satisfy (1) with the new LISTEN/NOTIFY, or is it
inadequate? I'll also point out that currently DEFFERABLE
CONSTRAINT/TRIGGERS can be perverted to work like an after-commit trigger.
For (3), it kind of depends on another item on the list, the DDL triggers.