X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 05B5656191 for ; Wed, 2 Mar 2005 07:23:03 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 55237-10 for ; Wed, 2 Mar 2005 07:22:53 +0000 (GMT) Received: from correo2.acens.net (correo2.acens.net [217.116.0.34]) by svr1.postgresql.org (Postfix) with ESMTP id D45E055E26 for ; Wed, 2 Mar 2005 07:22:51 +0000 (GMT) Received: (qmail 27658 invoked from network); 2 Mar 2005 07:22:51 -0000 Received: from unknown (HELO albert.sedifa.com) ([213.171.224.53]) (envelope-sender ) by correo2.acens.net (qmail-ldap-1.03) with SMTP for ; 2 Mar 2005 07:22:51 -0000 From: Albert Cervera Areny Organization: Sedifa, S.L. To: pgsql-interfaces@postgresql.org Subject: Re: Showing progress of a database function Date: Wed, 2 Mar 2005 08:22:51 +0100 User-Agent: KMail/1.7.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200503020822.51327.albert@sedifa.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.05 tagged_above=0 required=5 tests=FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200503/2 X-Sequence-Number: 5331 Would it be a solution for your problem to use LIMIT and OFFSET and make X= =20 iterations? A Dimarts 01 Mar=E7 2005 14:55, Tambet Matiisen va escriure: > Hi everybody! > > When designing database-centric applications it is always good idea to > push as much logic as possible to server side. The logic can be > implemented as check constraints, triggers and functions. The problem > is, that for lengthy function calls it will be impossible to see the > progress and to cancel the operation, unless your client library > supports asynchronous queries. Qt for example doesn't, like many others. > > My idea was to use cursor as progress indicator for the function. > Simplified example: > > create or replace function process_big_table() returns refcursor > language plpgsql as > declare > cur as refcursor; > begin; > open cur for > select process_row(id) > from big_table > where special_condition > order by special_order; > return cur; > end; > > As you see, there is another function process_row(), which does the > actual processing. This function has to be called for certain rows in > big table, in certain order. In client code I do something like this: > > begin; > select process_big_table(); -- returns the name of the cursor > loop > fetch next from ; > > > end loop > commit; > > I expected it to call process_row() every time I fetch a row. But > actually it processes all of them on first fetch and all following rows > are returned in constant time. Is this a normal way of operation? Or > does it depend on query? Are the query results always precalculated at > the server side and the save from using cursors is just not to download > all rows to client? > > If anyone has other ideas how to show progress of a database function, > then you are welcome to share. I have considered using notice > processing, but this requires access to libpq objects such as PGconn, > which can be tricky with Qt (altough possible, as Qt uses libpq > internally). And to be able to cancel requests I still need asynchronous > query API, which is missing in Qt. > > Tambet > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings =2D-=20 Albert Cervera Areny Dept. Inform=E0tica Sedifa, S.L. Av. Can Bordoll, 149 08202 - Sabadell (Barcelona) Tel. 93 715 51 11 =46ax. 93 715 51 12 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2E....................... AVISO LEGAL ............................ La presente comunicaci=F3n y sus anexos tiene como destinatario la persona a la que va dirigida, por lo que si usted lo recibe por error debe notificarlo al remitente y eliminarlo de su sistema, no pudiendo utilizarlo, total o parcialmente, para ning=FAn fin. Su contenido puede tener informaci=F3n confidencial o protegida legalmente y =FAnicamente expresa la opini=F3n del remitente. El uso del correo electr=F3nico v=EDa Internet no permite asegurar ni la confidencialidad de los mensajes ni su correcta recepci=F3n. En el caso de que el destinatario no consintiera la utilizaci=F3n del correo electr=F3nico, deber=E1 ponerlo en nuestro conocimiento inmediatamente. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2E.......................... DISCLAIMER ............................. This message and its attachments are intended exclusively for the named addressee. If you receive this message in error, please immediately delete it from your system and notify the sender. You may not use this message or any part of it for any purpose. The message may contain information that is confidential or protected by law, and any opinions expressed are those of the individual sender. Internet e-mail guarantees neither the confidentiality nor the proper receipt of the message sent. If the addressee of this message does not consent to the use of internet e-mail, please inform us inmmediately. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20