> Mark Woodward wrote: >>> "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? >> >> >> > > It won't solve it in the general case for clients that expect a result > set. ISTM that "use a cursor" is a perfectly reasonable answer, though.
I'm not sure I agree -- surprise! psql is often used as a command line tool and using a cursor is not acceptable. Granted, with an unaligned output, perhaps psql should not buffer the WHOLE result at once, but without rewriting that behavior, a COPY from query may be close enough. ---------------------------(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