On 8/2/06, Flemming Frandsen <ff@partyticket.net> wrote:
> Ian Harding wrote:
> > NOTIFY interacts with SQL transactions in some important ways.
> > Firstly, if a NOTIFY is executed inside a transaction, the notify
> > events are not delivered until and unless the transaction is
> > committed. This is appropriate, since if the transaction is aborted,
> > all the commands within it have had no effect, including NOTIFY. But
> > it can be disconcerting if one is expecting the notification events to
> > be delivered immediately.
>
> Yes, that's very nice, but it doesn't have *anything* to do with what I
> posted about.
>
Quite true, but it does indicate, to me at least, the fact that this
is a SQL command and doesn't take effect until committed.
From what I read in the docs, I would expect the NOTIFY signals to be
like phone calls, if your phone's not plugged in (LISTEN not
committed) you miss the call. That's the way it works apparently.
> I'm bothered by listen listening from the end of the transaction in
> stead of the start of the transaction.
>
What seems to be needed is an answering service that will record your
NOTIFY events, in case you decide to plug in the phone and retrieve
them.
- Ian
