From: Bruce Momjian <maillist@candle.pha.pa.us>
To: tgl@sss.pgh.pa.us
Cc: goran@bildbasen.se
Cc: pgsql-interfaces@postgreSQL.org
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [INTERFACES] Re: [HACKERS] Convert PGconn, PGresult to opaque types?
Date: Mon, 24 Aug 1998 11:34:41 -0400 (EDT)
Message-ID: <199808241534.LAA00982@candle.pha.pa.us> (raw)
In-Reply-To: <23263.903968555@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.
>
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.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: maillist@candle.pha.pa.us, tgl@sss.pgh.pa.us, goran@bildbasen.se, pgsql-hackers@postgreSQL.org
Subject: Re: [INTERFACES] Re: [HACKERS] Convert PGconn, PGresult to opaque types?
In-Reply-To: <199808241534.LAA00982@candle.pha.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox