Return-Path: aoki
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA27349; Tue, 1 Jun 93 22:40:24 -0700
Message-Id: <9306020540.AA27349@postgres.Berkeley.EDU>
From: aoki@postgres.berkeley.edu (Paul M. Aoki)
Subject: PQexec error handling
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Date: Tue, 01 Jun 93 22:40:54 -0700
Sender: aoki@postgres.Berkeley.EDU
X-Mts: smtp

PQexec currently returns "R" when you get a non-fatal error
(sometimes setting PQerrormsg, sometimes not) and calls exit(2)
on most "fatal" (backend coredump) errors.  this interface is
less than useful for intelligent error-handling.

ok.  it's not hard to fix libpq so that PQerrormsg is set more
consistently.  i've done that.  but people have also pointed out
(correctly, imo) that it's rather hostile for a library routine 
to call exit(2).  so, even though it's not currently-documented
behavior, i'll probably change PQexec so that it returns "E" and 
sets PQerrormsg on "fatal" errors, rather than exit'ing.  (i'm 
puzzled as to why it doesn't do this now.  this used to be 
documented behavior -- heck, the sample programs (and monitor) 
assume that it happens, but it doesn't.  don't know why.)
this seems to be the smallest change i can make without doing 
something massively weird to the interface.

anyway -- anyone have any major objections?

(i realize people would probably be deliriously happy if the whole
mess went away and was replaced with something better-engineered, 
but that probably won't happen any time real soon..)
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki
