From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200006100215.WAA08561@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: Update doc changes needed
In-Reply-To: <9550.953877665@sss.pgh.pa.us> "from Tom Lane at Mar 24,
	2000 01:01:05 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 9 Jun 2000 22:15:35 -0400 (EDT)
CC: SL Baur <steve@beopen.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	PostgreSQL-documentation <docs@postgresql.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

OK, seems the issue is closed.

> SL Baur <steve@beopen.com> writes:
> > I made a test patch last weekend if you want it.  It's been stress
> > tested in an XEmacs Lisp-calling-libpq environment.
> 
> > This patch adds a PQsetenvClear function that is analogous to the
> > clear function for PQresult's and changes the PQsetenvPoll call to
> > accept a PQsetenvHandle.  The PQsetenvHandle is freed automatically
> > when called during a database connect.  When the asynchronous setenv
> > calls are called by application code, it is now the responsibility of
> > the application code to free the setenvHandle with PQsetenvClear.
> 
> I think this is just throwing good work after bad.  The entire exercise
> can be eliminated by merging the two useful fields of the 'handle'
> object into PGconn (at a net cost of 4 bytes); there's no reason to do
> all the bookkeeping needed to keep track of a separate handle object.
> 
> I already did that, and de-exported the PQsetenv routines, earlier
> today.  Since I still haven't heard anyone make an argument why any
> app would want to call PQsetenv, I don't see a reason to do more work
> on these routines.
> 
> 			regards, tom lane
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026