Return-Path: postman Delivery-Date: Mon, 06 Sep 93 23:59:30 PDT Return-Path: postman Received: by postgres.Berkeley.EDU (5.61/1.29) id AA01431; Mon, 6 Sep 93 23:44:12 -0700 Resent-From: postman (POSTGRES mailing list) Resent-Message-Id: <9309070644.AA01431@postgres.Berkeley.EDU> Sender: owner-postman@postgres.Berkeley.EDU X-Return-Path: aoki Received: by postgres.Berkeley.EDU (5.61/1.29) id AA01419; Mon, 6 Sep 93 23:44:00 -0700 Message-Id: <9309070644.AA01419@postgres.Berkeley.EDU> From: aoki@postgres.Berkeley.EDU (Paul M. Aoki) To: Marc Salomon Cc: postgres@postgres.berkeley.edu Subject: Re: pgperl In-Reply-To: Your message of Fri, 3 Sep 1993 11:50:05 -0700 <199309031850.AA21201@library.ucsf.edu> Date: Mon, 06 Sep 93 23:43:59 PDT X-Sender: aoki Resent-To: postgres-dist Resent-Date: Mon, 06 Sep 93 23:44:10 PDT Marc Salomon writes: > |Error: No response from the backend, exiting... > Is there any way to catch this from within a pgperl script? the good news is that, in general, you should be able to catch the backend error message in PQerrormsg after PQexec returns with error status. (and this might actually work in this case. depending on the version of pgperl you're using, PQerrormsg might not be properly set up in the mus file.) the bad news is that many error messages are not properly loaded into PQerrormsg by libpq. the good news is that i diddled libpq so that it would load PQerrormsg as appropriate and avoid calling exit() under many conditions :-P the bad news is that the fix is a "wait 'til next release" fix, since it got caught in some random header restructuring and almost certainly won't compile under stock 4.1.. -- Paul M. Aoki | CS Div., Dept. of EECS, UCB | aoki@postgres.Berkeley.EDU | Berkeley, CA 94720 | ...!uunet!ucbvax!aoki