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

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

From: Jouni Ahto <jah(at)cultnet(dot)fi>
To: Eric Marsden <emarsden(at)mail(dot)dotcom(dot)fr>
Cc: pgsql-interfaces(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org, Zeev Suraski <bourbon(at)netvision(dot)net(dot)il>
Subject: Re: [INTERFACES] Convert PGconn, PGresult to opaque types?
Date: 1998-08-24 16:47:21
Message-ID: Pine.LNX.3.96.980824193447.29026B-100000@guru.cultnet.fi (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces

On 24 Aug 1998, Eric Marsden wrote:

> >>>>> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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


In response to

pgsql-hackers by date

Next:From: Florian WunderlichDate: 1998-08-24 17:17:23
Subject: Re: [GENERAL] DELETE statement KILL backend <AGAIN>
Previous:From: Brook MilliganDate: 1998-08-24 16:04:36
Subject: Re: [HACKERS] Open 6.4 items

pgsql-interfaces by date

Next:From: Peter T MountDate: 1998-08-24 16:59:58
Subject: Re: [INTERFACES] JDBC Connection
Previous:From: John ReillyDate: 1998-08-24 16:40:42
Subject: Re: [INTERFACES] JDBC Connection

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