> "Jim C. Nasby" <[EMAIL PROTECTED]> writes: >> On Mon, Jun 05, 2006 at 11:27:30AM -0400, Tom Lane wrote: >>> I'm reading this as just another uninformed complaint about libpq's >>> habit of buffering the whole query result. It's possible that there's >>> a memory leak in the -A path specifically, but nothing said so far >>> provided any evidence for that. > >> Certainly seems like it. It seems like it would be good to allow for >> libpq not to buffer, since there's cases where it's not needed... > > See past discussions. The problem is that libpq's API says that when it > hands you back the completed query result, the command is complete and > guaranteed not to fail later. A streaming interface could not make that > guarantee, so it's not a transparent substitution. > > I wouldn't have any strong objection to providing a separate API that > operates in a streaming fashion, but defining it is something no one's > bothered to do yet. In practice, if you have to code to a variant API, > it's not that much more trouble to use a cursor... >
Wouldn't the "COPY (select ...) TO STDOUT" format being discussed solve this for free? ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match