Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag
| От | Tom Lane |
|---|---|
| Тема | Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag |
| Дата | |
| Msg-id | 1996.1385585233@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag (Boszormenyi Zoltan <zb@cybertec.at>) |
| Ответы |
Re: Modify the DECLARE CURSOR command tag depending on
the scrollable flag
|
| Список | pgsql-hackers |
Boszormenyi Zoltan <zb@cybertec.at> writes:
> If you consider all these:
> - certain combinations of query and DECLARE stmt flags fail;
> - adding NO SCROLL is breaking backward compatibility;
> - the readahead code has to really know whether the cursor is
> scrollable so it can behave just like the server;
If you're claiming that readahead inside ECPG will behave absolutely
transparently in all cases, I think that's bogus anyway. Consider for
example a query that will get a divide-by-zero error when it computes
the 110th row --- but the application stops after fetching 100 rows.
Everything's fine, until you insert some readahead logic. Queries
containing volatile functions might also not be happy about readahead.
Given these considerations, I think it'd be better to allow explicit
application control over whether read-ahead happens for a particular
query. And I have no problem whatsoever with requiring that the cursor
be explicitly marked SCROLL or NO SCROLL before read-ahead will occur.
regards, tom lane
В списке pgsql-hackers по дате отправления: