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 KAA20865;
	Mon, 24 Aug 1998 10:22:52 -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 KAA23265;
	Mon, 24 Aug 1998 10:22:36 -0400 (EDT)
To: Goran Thyni <goran@bildbasen.se>
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 14:50:51 +0200
	<35E161AB.7DC7012A@bildbasen.se>
Date: Mon, 24 Aug 1998 10:22:35 -0400
Message-ID: <23263.903968555@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Goran Thyni <goran@bildbasen.se> writes:
> Bruce Momjian wrote:
>>>> Basically this would force applications to use the accessor functions
>>>> as recommended in the documentation, and not touch fields of a PGconn
>>>> object directly.  (Ditto for PGresult.)
>> 
>> I am scared about external stuff like php.  If they use it, and we
>> release something that doesn't work with their stuff, we are cooked
>> until they upgrade.

But if they are using any direct references to fields of the PGconn
struct, their stuff *already* won't work with 6.4.  Admittedly it'd
most likely only take a recompile to fix, and not code changes
(however trivial).  But if they'd been using only the documented API,
ie using the accessor functions and not directly touching the struct,
then a new shared library or DLL could be plopped right in without even
a recompile of calling applications.

Is the PHP source code available?  It wouldn't take much work to check
whether it will compile without a definition for struct pg_conn.

> I think Tom is aiming for thread-safeness which can't be done as long as
> external stuff insists on accessing global structs inside libpq.

This is not a thread-safeness issue, it's an issue of being able to
promise binary compatibility across versions.  Before the days of shared
libraries, source-code compatibility across versions was Good Enough,
because users had to rebuild their apps anyway to drop in a new version
of a library.  Nowadays, people who don't even *have* the source of an
app still expect that they can shove in a new version of a shared library
that the app depends on.  And that's a good thing, if it fixes some bugs
or adds new features; but it only works if the library's API is fully
binary compatible across releases.  Hiding all but the simplest, most
stable structs is a necessary restriction if you hope to achieve that.

I made the wrong choice on this years ago with libjpeg (in self-defense,
that was before anyone had heard of shared libraries for Unix): I
exposed as part of the library's API a large parameter struct that I
knew would need to change with every new library version.  At the time
it didn't seem like a problem, but I've learned to regret it.  I see
people complaining all the time that their apps compiled against
libjpeg v6a stop working when they drop in v6b instead.  Learn
from my bad example ;-)

Basically my feeling is that we will want to do this eventually, and
the pain level can only get worse the longer we put it off.

			regards, tom lane