Re: [PATCHES] libpq type system 0.9a

Tom Lane wrote:
> 
> Hmm.  I guess it wouldn't be completely out of the question to expose
> the contents of PGresult as part of libpq's API.  We haven't changed it
> often, and it's hard to imagine a change that wouldn't be associated
> with a major-version change anyhow.  We could do some things to make it
> a bit more bulletproof too, like change cmdStatus from fixed-size array
> to pointer to allocated space so that CMDSTATUS_LEN doesn't become
> part of the API.
> 
> Alternatively, we could keep it opaque and expose a bunch of manipulator
> routines, but that might be a lot more cumbersome than it's worth.
> 
>             regards, tom lane
> 

How about a proxy header (if such an animal exists).  Maybe it is 
possible to take pg_result, and all structs it references, and put it in 
result-int.h.  libpq-int.h would obviously include this.  Also, any 
external library, like libpqtypes, that need direct access to a result 
can include result-int.h.  This keeps pg_result and referenced structs 
out of libpq-fe.h.  From a libpq user's viewpoint, nothing has changed.

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/