On Wed, Mar 03, 2010 at 09:42:22AM -0800, Josh Berkus wrote:
> (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.
I'm not sure I like the idea of this. Could be potentially dangerous, as
listen/notify is not treated as a "reliable" process. What's wrong with
the current method, namely having a row trigger update an internal
table, and then a statement level trigger firing off a notify?
> (2) A generic yet compact portable serialization format for a row of
> PostgreSQL data, just as protobuf, or something internal.
Jan has been tinkering with this for some time (granted, in a slightly
different context, but basically something faster and lower level
than COPY, that could perhaps be fed something external).
> (3) A method of marking DDL changes in the data modification stream.
Hmm..can you expand on what you have in mind here? Something more than
just treating the DDL as another item in the (txn ordered) queue?
Greg Sabino Mullane greg(at)endpoint(dot)com
End Point Corporation
PGP Key: 0x14964AC8
In response to
pgsql-cluster-hackers by date
|Next:||From: Josh Berkus||Date: 2010-03-03 19:52:52|
|Subject: Re: Spec discussion: Generalized Data Queue
/ Modification Trigger|
|Previous:||From: Christopher Browne||Date: 2010-03-03 18:32:22|
|Subject: Re: Expanded information template|