On Thu, Apr 13, 2006 at 12:12:25PM +0100, Dave Page wrote: > > Ok. I'm not sure what this "double copying" you're referring > > to is, > > The libpq driver copies results out of the PGresult struct into the > internal QueryResult classes. With libpq out of the loop, data can go > straight from the wire into the QR.
Hmm, the simplest improvement I can think of is one where you register a callback that libpq calls whenever it has received a new tuple. However, w.r.t. the copying, the pointers in get PGresult are in memory belonging to that result. As long as that PGresult hangs around, you should be able to just copy the pointers rather than the data? Or is this unacceptable? The only alternative I can think of is let users provide a callback that is given the number of bytes and it returns memory to store the data into. But that just seems unnecessarily complex, considering you could just copy the pointers. > There are elements of the wire protocol that libpq doesn't actually > implement from what I recall. IIRC, they were added specifically for > JDBC but also intended to be used by psqlODBC as well. I forget the > details though as I wasn't so involved with the ODBC development back > then. Ugh, that's terrible. How do these features get tested if nothing within the main tree implements them. > In addition of course, implementing the protocol natively does allow for > maximum flexibility. Maybe, but it should be possible to have a lot of flexibility without having many projects jump through all sorts of hoops everytime a new protocol version is created. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
signature.asc
Description: Digital signature
