> 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.
In response to
pgsql-cluster-hackers by date
|Next:||From: Josh Berkus||Date: 2010-03-03 18:12:29|
|Subject: Re: Expanded information template|
|Previous:||From: Markus Wanner||Date: 2010-03-03 15:21:01|
|Subject: Re: PgCon: who will be there?|