X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 41CDCD1CA6D for ; Tue, 14 Oct 2003 16:49:52 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 39468-05 for ; Tue, 14 Oct 2003 13:49:21 -0300 (ADT) Received: from wind.ukr.net (wind.ukr.net [212.42.64.10]) by svr1.postgresql.org (Postfix) with ESMTP id 03662D1C9E4 for ; Tue, 14 Oct 2003 13:46:07 -0300 (ADT) Received: from 82-16.odessa.dialup.ukr.net ([212.42.82.16]) by wind.ukr.net with esmtp ID 1A9SJ9-0002Bn-19 ; Tue, 14 Oct 2003 19:46:03 +0300 From: Igor Shevchenko To: Tom Lane Subject: Re: libpq/async notifications Date: Tue, 14 Oct 2003 19:46:07 +0300 User-Agent: KMail/1.5.2 References: <200310111220.25923.igor@carcass.ath.cx> <9884.1066147821@sss.pgh.pa.us> In-Reply-To: <9884.1066147821@sss.pgh.pa.us> Cc: pgsql-interfaces@postgresql.org MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310141946.07374.igor@carcass.ath.cx> X-HOSTING.UKR.NET-ID: 6c04093d8f25a410825a4361d42618a7 X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200310/31 X-Sequence-Number: 4520 On Tuesday 14 October 2003 19:10, Tom Lane wrote: > Igor Shevchenko 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