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