From: | Radosław Smogura <rsmogura(at)softperience(dot)eu> |
---|---|
To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
Cc: | Pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Proposition fetch cursors |
Date: | 2011-06-14 13:33:15 |
Message-ID: | 0f12920b873b83d1c124b17eb9fa2784@mail.softperience.eu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 14 Jun 2011 20:49:48 +0800, Craig Ringer wrote:
> On 06/14/2011 04:30 PM, Radosław Smogura wrote:
>> Hello,
>>
>> I have proposition about one missing feature for cursors. Actually
>> there
>> is no support for fetching some data from cursor without moving it
>> (in
>> context of external applications). This could be nice if driver
>> could
>> fetch e.g. 100 rows, buffer it internally and then move cursor at
>> desired position in order to update data. I think this is known
>> approach
>> in databases.
>
> Interesting.
>
> Do you want this only for scrollable cursors? Or do you want/need to
> be able to "peek" ahead into the results of a non-scrollable cursor
> too?
>
> What's your use case?
>
> --
> Craig Ringer
Actually for "for update" cursors (so for all non-scrollable). With
scrollable I can move backward and forward simulating fetches, but for
update it's small pain, as in order to update n-th row (I doesn't know
at begin that this is n-th row) I should ask n-times to get this row,
moving forward one-by-one - adding network "overhead". With fetches I
can ask to fetch 100 rows from current position, process it on my side,
and then decide where to move cursor (eventually to update data).
Regards,
Radek
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2011-06-14 13:45:47 | Re: Tweaking bytea / large object block sizes? |
Previous Message | Craig Ringer | 2011-06-14 13:05:06 | Re: determine client os |