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/
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
