Re: Spec discussion: Generalized Data Queue / Modification Trigger

> 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