On 24 Aug 1998, Eric Marsden wrote:
> >>>>> "TL" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> (sorry, attributions are lost here)
>
> >>>>> 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.
> TL>
> TL> But if they are using any direct references to fields of the PGconn
> TL> struct, their stuff *already* won't work with 6.4. Admittedly it'd
> TL> most likely only take a recompile to fix, and not code changes
> TL> (however trivial). But if they'd been using only the documented API,
> TL> ie using the accessor functions and not directly touching the struct,
> TL> then a new shared library or DLL could be plopped right in without even
> TL> a recompile of calling applications.
> TL>
> TL> Is the PHP source code available? It wouldn't take much work to check
> TL> whether it will compile without a definition for struct pg_conn.
>
> The PHP source is available from http://www.php.net/. From a quick
> look through it, it does access the PGconn structure directly. Stuff
> like (this is from the file php3.0.2a/functions/pgsql.c):
>
> lo_read((PGconn *)pgsql->conn, pgsql->lofd, buf, 8192))
Shouldn't be a problem. In this case, pgsql is is pointer to a struct
typedef struct pgLofp {
PGconn *conn;
int lofd;
} pgLofp;
so, pgsql->conn is a pointer to a PGconn struct to pass to lo_read, but
the code doesn't touch or refer anywhere to the members of that struct.
Anyway, I'll try to keep an eye on what's happening on pgsql-hackers list.
> However, the whole PostgreSQL-specific stuff is only 1400 lines worth,
> and the PHP guys are reputed to very active, so I don't think a change
> should pose too much of a problem if they are forewarned.
Jouni Ahto
