Обсуждение: migration to v6.5

Hi.

Ive recently looked into porting an internal tool our company uses to
version 6.5 of postgresql (from 6.4.2).  Unfortunately, the original author
of this tool used items like:

PGresult *res;
...
myconn = res->conn;

in a few spots (usually to be used to query pg_type to get string typename
for come columns of the result set).  Looking through the libpq headers, it
does appear that the PGconn member of the struct is still there, but the
struct definition (struct pg_result) has been hidden from applications via
moving the struct definitions to a nother file.

I realize that using code like the above is a BadThing(tm), and if I were
writing the application, I would not have done it that way.  However, if I
am going to port this application to v6.5, it will require some workaround.
My question is this:  If the PGresult struct contains a PGconn member,
should there be an accessor function for it?  Or is this member considered
to be private?  If so, I guess I will have to rewrite a large section of
this application from scratch, but I thought I would check on the reasoning
for the move of the conn member here first.

Thanks for all the hard work guys.  

Regards,
Mike

Michael J Schout <mschout@mail.gkg-com.com> writes:
> My question is this:  If the PGresult struct contains a PGconn member,
> should there be an accessor function for it?  Or is this member considered
> to be private?  If so, I guess I will have to rewrite a large section of
> this application from scratch, but I thought I would check on the reasoning
> for the move of the conn member here first.

I had intended to remove that member entirely, but desisted in order to
grant some breathing room to people in your situation ;-).  For the
moment you can access it if you include libpq-int.h in your application.

The reasoning for removing it is that a PGresult could outlive the
PGconn it was produced from, leaving you with a dangling pointer.

I would like to remove it eventually, but probably won't do so for
another version or two.
        regards, tom lane