Re: [INTERFACES] Convert PGconn, PGresult to opaque types?
От | Jouni Ahto |
---|---|
Тема | Re: [INTERFACES] Convert PGconn, PGresult to opaque types? |
Дата | |
Msg-id | Pine.LNX.3.96.980824193447.29026B-100000@guru.cultnet.fi обсуждение исходный текст |
Ответ на | Re: [INTERFACES] Convert PGconn, PGresult to opaque types? (Eric Marsden <emarsden@mail.dotcom.fr>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: