> 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
spec.
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.
Discussion?
--Josh Berkus