Re: NOTIFY/LISTEN why is not a callback as notice processing. - Mailing list pgsql-general

From Steve Atkins
Subject Re: NOTIFY/LISTEN why is not a callback as notice processing.
Date
Msg-id 9FE6A1CD-E7C1-4015-880F-4975913D47BD@blighty.com
Whole thread Raw
In response to Re: NOTIFY/LISTEN why is not a callback as notice processing.  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-general
On Nov 10, 2010, at 4:30 PM, Daniel Verite wrote:

>     Filonenko Michael wrote:
>
>> I create simple mechanism to inform user about something in database
>> triggers. In my front-end I use PQsetNoticeReceiver, and display messages
>> in QTextEdit.
>> I think about multi-user environment. I read about NOTIFY/LISTEN, but find
>> no callback mechanism. Is it planning?
>
> Not sure what the multi-user environment implies, but since you're using Qt,
> you're probably interested in getting a Qt signal when a db notification
> arrives. It turns out it's not hard to do: before calling LISTEN, instantiate
> a QSocketNotifier object bound to the socket of the libpq connection, and
> connect its activated() signal to a slot. In this slot, your code can deal
> with the notification at the libpq level with PQconsumeInput() and
> PQnotifies(), do your own processing, and just return.
> With this method, you don't have any need for a callback or managing your own
> loop: it is Qt's event loop that calls the slot, just as it does for
> GUI-related events.

It's even easier than that - Qt supports listen/notify directly.

QSqlDriver::subscribeToNotification(), and connect the the notification()
signal.

Cheers,
  Steve


pgsql-general by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: NOTIFY/LISTEN why is not a callback as notice processing.
Next
From: Devrim GÜNDÜZ
Date:
Subject: Re: PostgreSQL 8.2.3