On Tuesday 14 October 2003 19:10, Tom Lane wrote:
> Igor Shevchenko <igor@carcass.ath.cx> writes:
> > Is there a way to only check if there's any pending async notifications ?
> > I've found only PQnotifies(..) but it also removes the first notification
> > from the list.
> > A function for only checking this can be used in a gui app to setup async
> > notifications processing so it happens only after an app reaches it's
> > main loop (which is a good idea since it won't happen in the middle of
> > another app's handler function which happens to use pgsql database
> > interface). Currently I have to check for notifications with PQnotifies
> > every time my app returns to the main loop after using any of PGexec,
> > etc, which is not very efficient.
>
> "Not very efficient"? This seems like a very weak argument. The actual
> cost of running the function is no different from PQnotifies in the case
> where no notify event is found; and in the case where one is found, it'd
> be slower because you'd then have to call PQnotifies anyway to remove
> the item from the list.
The idea behind this checking function is to separate the *checking* if
there's any notifications and actually *processing* them. I want to check
right after any transaction or any PQ* function which calls PQconsumeInput
and process notifications only once, after my app had returned to it's main
loop (I'm talking about GUI apps here). In Qt, for example, this is done by
creating a new QEvent and dispatching it via QApplication::postEvent(...),
which is quite an overhead; with just PQnotifies I have to do this all the
time.
>
> Yes, I know the function is only five lines, but there are also
> documentation and other maintenance costs to consider anytime we add
> something to libpq's API. I don't think you've made enough of a case
> for it.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
Best regards,
Igor Shevchenko
