From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: C libpq frontend library fetchsize |
Date: | 2010-03-19 23:12:40 |
Message-ID: | 603c8f071003191612n5a2fd8c6rae6d9857baad8364@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 18, 2010 at 1:21 PM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
> Tom Lane wrote:
>>
>> Yeb Havinga <yebhavinga(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-03-20 00:11:13 | Re: [BUG] SECURITY DEFINER on call handler makes daemon crash |
Previous Message | Robert Haas | 2010-03-19 23:06:06 | Re: [BUG] SECURITY DEFINER on call handler makes daemon crash |