Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] Re: [HACKERS] Convert PGconn, PGresult to opaque types?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Goran Thyni <goran(at)bildbasen(dot)se>
Cc: pgsql-interfaces(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] Re: [HACKERS] Convert PGconn, PGresult to opaque types?
Date: 1998-08-24 14:22:35
Message-ID: 23263.903968555@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
Goran Thyni <goran(at)bildbasen(dot)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

Responses

pgsql-hackers by date

Next:From: John ReynoldsDate: 1998-08-24 14:25:32
Subject: subscribe
Previous:From: Bruce MomjianDate: 1998-08-24 14:19:32
Subject: Re: [HACKERS] initdb problem

pgsql-interfaces by date

Next:From: Byron NikolaidisDate: 1998-08-24 14:29:48
Subject: Re: [INTERFACES] iodbc interface on Unix
Previous:From: Eric MarsdenDate: 1998-08-24 13:40:25
Subject: Re: [INTERFACES] JDBC Connection

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group