Andrew Chernow <[EMAIL PROTECTED]> writes:
>>> What parts of PGconn/PGresult do you need to touch that aren't exposed
>>> already?
> Don't need direct access to PGconn at all.
Oh, good, that makes things much easier.
> Also, we basically need write access to every member inside a result
> object ... since we create our own for arrays and composites by copying
> the standard result members over.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
