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 f43JgPA70428
	for <pgsql-interfaces@postgresql.org>;
	Thu, 3 May 2001 15:42:25 -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 f43JgHR00821;
	Thu, 3 May 2001 15:42:17 -0400 (EDT)
To: justinb@tricord.com
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
	PostgreSQL-interfaces <pgsql-interfaces@postgresql.org>
Subject: Re: Re: libpq++ 
In-reply-to: <15089.45940.490466.456420@idoru.tricord.com> 
References: <200105031915.f43JFpf12056@candle.pha.pa.us>
	<299.988917936@sss.pgh.pa.us>
	<15089.45940.490466.456420@idoru.tricord.com>
Comments: In-reply-to Justin Banks <justinb@tricord.com>
	message dated "Thu, 03 May 2001 14:37:24 -0500"
Date: Thu, 03 May 2001 15:42:16 -0400
Message-ID: <818.988918936@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Archive-Number: 200105/13
X-Sequence-Number: 1539

Justin Banks <justinb@tricord.com> writes:
> You're right - this only works because the shared connections all
> occur in the same address space. It doesn't buy you anything between
> applications, only inside an application. The problem is that there's
> no way for different instantiations of classes inheriting
> database-ness from the PgDatabase class to share a PGconn* unless the
> PgDatabase class provides a way for different instantiations to know
> that existing connections are available.

And what's wrong with a static class variable for that purpose?
The shmem segment looks like the hardest possible way to get the
same result.

			regards, tom lane