Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org
	(8.8.8/8.7.5) with ESMTP id RAA24269;
	Mon, 24 Aug 1998 17:52:32 -0400 (EDT)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA25058;
	Mon, 24 Aug 1998 17:52:20 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: pgsql-interfaces@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [INTERFACES] Re: [HACKERS] Convert PGconn,
	PGresult to opaque types?
In-reply-to: Your message of Mon, 24 Aug 1998 11:34:41 -0400 (EDT)
	<199808241534.LAA00982@candle.pha.pa.us>
Date: Mon, 24 Aug 1998 17:52:20 -0400
Message-ID: <25056.903995540@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> I am convinced.  Hide the structure members, and lets go through beta
> like that.  If we have problems, we can supply a patch to expose the
> structure members, with the knowledge there will be no workaround patch
> for 6.5.  They have to fix it by then.

Actually, the "patch" will just be to #include libpq-int.h along with
lipq-fe.h.  I arranged for libpq-int.h to be one of the installed header
files, with the idea that some people would rather do that than fix
their code properly.  It's their choice: if they want to depend on libpq
internals and have a greater risk of their code breaking across
releases, they can.  I just want to discourage that a little bit, and
make it real clear what's considered supported API and what's considered
internal detail.

			regards, tom lane