X-Original-To: pgsql-interfaces@postgresql.org Received: from localhost (unknown [64.117.224.193]) by developer.postgresql.org (Postfix) with ESMTP id 76DC2925BC2 for ; Thu, 22 May 2003 22:56: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 93076-02 for ; Thu, 22 May 2003 22:56:20 -0400 (EDT) Received: from luna.lyris.com (luna.lyris.com [216.91.57.116]) by developer.postgresql.org (Postfix) with ESMTP id 3026A9257B8 for ; Thu, 22 May 2003 20:24:01 -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 h4N0NjWW019839 for ; Thu, 22 May 2003 17:23:45 -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); Thu, 22 May 2003 17:23:45 -0700 From: Forest Wilkinson To: pgsql-interfaces@postgresql.org Subject: Re: PGRES_FATAL_ERROR from queries in transaction abort state? Date: Thu, 22 May 2003 17:23:45 -0700 Message-ID: References: <12311.1053648387@sss.pgh.pa.us> In-Reply-To: <12311.1053648387@sss.pgh.pa.us> 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-interfaces@postgresql.org X-SMTP-PEER-INFO: forest.lyris.com [216.91.56.45] X-Virus-Scanned: by amavisd-new X-Archive-Number: 200305/51 X-Sequence-Number: 4169 >> I am maintaining code that uses libpq, and takes PGRES_FATAL_ERROR to >> mean the database connection can no longer be used. > >It has never meant that. Only connection status going to CONNECTION_BAD >would mean that. Okay. What does it mean? >I think that the original design intended the code PGRES_NONFATAL_ERROR >to be used for what we now call a WARNING; but in point of fact it's not >being used at all, because warnings aren't reported through >PQresultStatus.=20=20 In that case, wouldn't PGRES_NONFATAL_ERROR be a more appropriate choice for queries that fail due to an aborted transaction? I can't think of how this condition could be considered fatal. >AFAICS the *only* case where you get >PGRES_NONFATAL_ERROR is when you pass a null PGresult pointer to >PQresultStatus(),=20 I got one today by passing ";" to PQexec().