Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> No, that's not what I'm thinking about at all, and I don't think Martijn
>> is either. The point here is that ODBC wants to store the resultset in
>> a considerably different format from what libpq natively provides, and
>> we'd like to avoid the conversion overhead.
> So how would you provide the data to the callback? And how does having a
> callback instead of a regular downcall give you any more flexibility in how
> you present the data?
You'd hand the callback the raw data coming off the wire (pointer and
byte count, probably), and then it could do whatever's appropriate. For
instance, if the callback knows this field is to be converted to int, it
could do atoi() and then store the integer. (Or if it knows the data is
transmitted in binary, ntohl() would be the thing instead.)
The basic point here is that the callback should replace all the parts
of getAnotherTuple() that are responsible for storing data into the
PGresult structure, including all of pqAddTuple. If you aren't
satisfied with the PGresult representation, that's the level of
flexibility you need, IMHO. I don't see the point of half-measures.
Probably there would need to be at least three callbacks involved:
one for setup, called just after the tuple descriptor info has been
received; one for per-field data receipt, and one for per-tuple
operations (called after all the fields of the current tuple have
been passed to the per-field callback). Maybe you'd want a shutdown
callback too, although that's probably not strictly necessary since
whatever you might need it to do could be done equally well in the
app after PQgetResult returns. (You still want to return a PGresult
to carry command success/failure info, and probably the tuple descriptor
info, even though use of the callbacks would leave it containing none of
the data.)
A useful finger exercise for validating the design would be to code up
the default callbacks, ie, code to build the current PGresult structure
using this API.
regards, tom lane
