Received: from sss.pgh.pa.us (sss.pgh.pa.us [216.151.103.158])
	by postgresql.org (8.11.3/8.11.1) with ESMTP id f43JRDA64952
	for <pgsql-interfaces@postgresql.org>;
	Thu, 3 May 2001 15:27:15 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.11.3/8.11.3) with ESMTP id f43JPbR00302;
	Thu, 3 May 2001 15:25:37 -0400 (EDT)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: justinb@mr-boo.com, justinb@tricord.com,
	PostgreSQL-interfaces <pgsql-interfaces@postgresql.org>
Subject: Re: Re: libpq++ 
In-reply-to: <200105031915.f43JFpf12056@candle.pha.pa.us> 
References: <200105031915.f43JFpf12056@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
	message dated "Thu, 03 May 2001 15:15:51 -0400"
Date: Thu, 03 May 2001 15:25:36 -0400
Message-ID: <299.988917936@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Archive-Number: 200105/14
X-Sequence-Number: 1540

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I think he is creating his own shared memory area:

Oh, I see.  Isn't that pretty silly, considering that there's no way
for such objects to share a DBconnection if they are in different
application processes?  Seems like a simple static variable would do
the job just as well with a lot fewer portability and resource-leakage
issues...

			regards, tom lane