Re: [INTERFACES] Re: [HACKERS] Convert PGconn, PGresult to opaque types? - Mailing list pgsql-interfaces
From | Bruce Momjian |
---|---|
Subject | Re: [INTERFACES] Re: [HACKERS] Convert PGconn, PGresult to opaque types? |
Date | |
Msg-id | 199808241534.LAA00982@candle.pha.pa.us Whole thread Raw |
In response to | Re: [INTERFACES] Re: [HACKERS] Convert PGconn, PGresult to opaque types? (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [INTERFACES] Re: [HACKERS] Convert PGconn, PGresult to opaque types?
(Tom Lane <tgl@sss.pgh.pa.us>)
|
List | pgsql-interfaces |
> 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)
pgsql-interfaces by date: