> "Jim C. Nasby" <jnasby@pervasive.com> 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?
