Greg Stark <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly