* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Right... As I mentioned, the application can use cursors to
> > *work-around* this foolishness in libpq but that doesn't really make it
> > any less silly.
>
> Before you define libpq's behavior as "foolishness", you really ought to
> have a watertight semantics for what will happen in your proposal when a
> SELECT fails partway through (ie, after delivering some but not all of
> the tuples). In my mind the main reason for all-or-nothing PGresult
> behavior is exactly to save applications from having to deal with that
> case.
The library would report an error when trying to finish reading the
data. Honestly, that just isn't libpq's problem, it's the application's
problem to deal with it and I know that *I* certainly wouldn't have any
expectation (or faith...) in libpq doing the right thing for my
particular application in any given failure case.
The library should report error conditions, not assume that I'd only
want all-or-nothing anyway. I'm not all about breaking backwards
compatibility though and so I'm not suggesting we change the existing
behavior in this regard. This should not be an impediment to an
addition to the API to allow for reading the data as it comes in.
This certainly isn't unheardof or unexpected in the database world
either as (at least) Oracle's library doesn't do this collect-everything
and make-sure-it's-all-happy before returning data to the user. Not to
mention the potential for something bad to happen *while* reading the
data out of libpq. For example, having the machine crash because you've
run it out of memory because you've got at least 2 and probably 3 copies
of the data in memory (ie: ODBC under Windows with libpq). libpq might
have been correct to provide data to the client since it was sure it had
it all but it doesn't help a bit when because of libpq the box runs out
of memory.
Thanks,
Stephen