Andrew Chernow <[EMAIL PROTECTED]> writes:
> 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.
> How about a proxy header (if such an animal exists).
A separate header might be a good idea to discourage unnecessary
reliance on the struct, but it doesn't change the basic fact that
we'd be adding the struct to our ABI and couldn't change it without
a major library version number bump.
Perhaps we could do a partial exposure, where the exported struct
declaration contains "public" fields and there are some "private" ones
after that. This would still work for external creation of PGresults,
so long as all PGresults are initially manufactured by
PQmakeEmptyPGresult. That would give us a little bit of wiggle room
... in particular I'd be very tempted not to expose the fields
associated with space allocation (we could export pqResultAlloc
instead), nor anything not foreseeably needed by libpgtypes.
> Maybe it is
> possible to take pg_result, and all structs it references, and put it in
> result-int.h.
I'd think something like libpq-result.h would be a better choice of
name. The other seems likely to collide with who-knows-what from
other packages,
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
