X-Original-To: pgsql-sql@postgresql.org Received: from localhost (developer.postgresql.org [64.117.224.193]) by developer.postgresql.org (Postfix) with ESMTP id EB45B9234D9 for ; Tue, 27 May 2003 18:53:51 -0400 (EDT) Received: from developer.postgresql.org ([64.117.224.193]) by localhost (developer.postgresql.org [64.117.224.193:10024]) (amavisd-new) with ESMTP id 29150-06 for ; Tue, 27 May 2003 18:53:50 -0400 (EDT) Received: from luna.lyris.com (luna.lyris.com [216.91.57.116]) by developer.postgresql.org (Postfix) with ESMTP id DE6F59250F7 for ; Tue, 27 May 2003 18:53:49 -0400 (EDT) Received: from luna.lyris.com (luna.lyris.com [216.91.57.116]) by luna.lyris.com (8.12.8/8.12.8) with SMTP id h4RMrYWW022481 for ; Tue, 27 May 2003 15:53:34 -0700 Received: from forest (forest.lyris.com [216.91.56.45]) by luna.lyris.net with SMTP (MailShield v2.04 - LINUX Jul 17 2001 16:58:31); Tue, 27 May 2003 15:53:34 -0700 From: Forest Wilkinson To: pgsql-sql@postgresql.org Subject: Empty queries guaranteed to work? Date: Tue, 27 May 2003 15:53:26 -0700 Message-ID: <41r7dvgk50cs46thfsk7shdbg9tbjeninq@4ax.com> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-SMTP-HELO: forest X-SMTP-MAIL-FROM: lyris-pg@tibit.com X-SMTP-RCPT-TO: pgsql-sql@postgresql.org X-SMTP-PEER-INFO: forest.lyris.com [216.91.56.45] X-Virus-Scanned: by amavisd-new X-Archive-Number: 200305/531 X-Sequence-Number: 13696 Tom Lane mentioned in this post that an empty query can be sent to the server to determine whether the connection is still good: http://archives.postgresql.org/pgsql-hackers/2001-10/msg00643.php Is a query of "" guaranteed to work as long as the connection is good? What about ";" or " "? Background: I am maintaining some postgres client code (C++/libpq) that, during exception handling for a failed query, must determine whether the database connection is still good. This check is currently done by sending a "select version()" query and checking the result. However, even that simple query fails with PGRES_FATAL_ERROR when the connection is still good, if executed in an aborted transaction. (I have no idea why in the world a fatal error would be reported, when the connection is perfectly good and a rollback is all that's needed.) I need to be able to distinguish this situation from a real fatal error, and PQstatus() appears to be unreliable for this purpose. A "" query that returns PGRES_EMPTY_QUERY seems to be a good indicator that the connection is good, even within aborted transactions. Now I just need to know whether this is documented and guaranteed to work. Suggestions of alternative methods are welcome.