Message-ID: <38FF4C3F.D79FCF4D@wgcr.org>
Date: Thu, 20 Apr 2000 14:28:15 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Tim Brookes <tim.brookes@mcmail.com>, pgsql-interfaces@postgreSQL.org
Subject: Re: libpq++ tracing considered harmful (was Re: libpq++
	memory problems)
References: <38FB6FA1.C63B030B@mcmail.com> <16483.956019092@sss.pgh.pa.us>
	<38FEB8DB.DBC3460E@mcmail.com> <2182.956243193@sss.pgh.pa.us>
	<38FF2126.9525DB82@mcmail.com> <38FF243E.E5C0E87E@wgcr.org>
	<8163.956252492@sss.pgh.pa.us> <38FF471B.4463ECF2@wgcr.org>
	<8280.956254952@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> >> Perhaps something can be salvaged from the wreckage, but for now the
> >> right answer is just to make sure that this code is not compiled.
 
> > And to compile this code you supply _which_ configure option?
 
> It isn't a configure option --- you have to edit libpq++'s makefile
> to enable it.  Or, in the case of the 6.5.* code, it got turned on
> anyway :-(.

Now that is just grand.  It will be a happy day once all the various
configuration options, both runtime and compiletime, are brought under
the GrandReUnification umbrella that Peter E is weaving right now....  

> Fortunately there is no security hole in either 6.5.*
> or current, since the code is too broken to actually produce any
> trace output, compiled or not.

That's what I thought you said.  Which, in this case, a bug was a good
thing -- as if the code hadn't been buggy, we'd have had a security bug.
~:-] 

> My point was mainly that I thought
> we should remove the code rather than fix it.

Who added the code in the first place?  Would anyone _need_ it? 
Otherwise, I agree -- _can_ it, if it's not too big of a change this
close to release (methinks not, but, you never know).

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11