On Thu, Mar 18, 2010 at 1:21 PM, Yeb Havinga <yebhavinga@gmail.com> wrote:
> Tom Lane wrote:
>>
>> Yeb Havinga <yebhavinga@gmail.com> writes:
>>
>>>
>>> What if the default operation of e.g. php using libpq would be as
>>> follows: set some default fetchsize (e.g. 1000 rows), then just issue
>>> getrow. In the php pg handling, a function like getnextrow would wait for
>>> the first pgresult with 1000 rows. Then if the pgresult is depleted or
>>> almost depleted, request the next pgresult automatically. I see a lot of
>>> benefits like less memory requirements in libpq, less new users with why is
>>> my query so slow before the first row, and almost no concerns.
>>>
>>
>> You are blithely ignoring the reasons why libpq doesn't do this. The
>> main one being that it's impossible to cope sanely with queries that
>> fail partway through execution.
>
> I'm sorry I forgot to add a reference to your post of
> http://archives.postgresql.org/pgsql-general/2010-02/msg00956.php which is
> the only reference to queries failing partway that I know of. But blithely
> is not a good description of me ignoring it. I though about how queries
> could fail, but can't think of anything else than e.g. memory exhaustion,
> and that is just one of the things that is improved this way. Maybe a user
> defined type with an error on certain data values, but then the same arguing
> could be: why support UDT? And if a query fails during execution, does that
> mean that the rows returned until that point are wrong?
>>
>> The described implementation would not
>> cope tremendously well with nonsequential access to the resultset, either.
>>
>
> That's why I'm not proposing to replace the current way pgresults are made
> complete, but just an extra option to enable developers using the libpq
> libary making the choice themselves.
This seems pretty reasonable to me, especially considering that JDBC
is apparently already doing it. I suppose there will always be
projects that want to reimplement the backend protocol so that they
can be "pure" some-language, but chipping away at the list of other
reasons why someone might not want to use libpq still seems like a
good idea.
...Robert