From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Theodore Petrosky <tedpet5(at)yahoo(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: help with rule and notification |
Date: | 2003-10-02 03:10:59 |
Message-ID: | 11905.1065064259@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Theodore Petrosky <tedpet5(at)yahoo(dot)com> writes:
> create rule r1 as on update to table1 do (update
> table2 set jobno = table1.jobno; notify table2;)
> so anyone listening for notifications on table2 can
> ask table2 for the jobno that was updated. then if
> they were viewing that jobno, update their display. if
> not just ignore the notify.
At the moment, a NOTIFY cannot convey very much information beyond
"something happened, better look to see what". (There have been
discussions about making the notification carry more info, see the
pgsql-hackers archives.) In a previous lifetime I had a moderately
complex application that used NOTIFY to trigger display updates for
multiple client apps viewing a shared database. If memory serves,
I did it by having a "sequence number" column that was assigned from
a nextval() operation on every insert or update. In addition the
inserts and updates triggered NOTIFY events. When the clients
got NOTIFY they'd do "select from tab where seqno > last-seqno-seen"
and then update their local state from the rows they got back.
This solution doesn't directly handle deletes. I think I finessed the
problem by treating "delete" as "update to a 'dead' state" and only
cleaning out the dead rows later.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-10-02 03:18:07 | Re: Creating Index |
Previous Message | CN | 2003-10-02 02:50:48 | Re: help with rule and notification |