Re: ECPG FETCH readahead

On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote:
> 2012-03-29 19:03 keltez?ssel, Noah Misch ?rta:

>>>> one of the new sections about readahead should somehow reference the hazard
>>>> around volatile functions.
>>> Done.
>> I don't see the mention in your latest patch. You do mention it for the
>> sqlerrd[2] compatibility stuff.
>
> sqlerrd[2] compatibility stuff? I mentioned it in section "ecpg-sqlca", this is the main
> documentation section, not the compatibility one AFAIK. Anyway, I now reference the volatile
> function hazard in the first paragraphs added to section "ecpg-cursors".

This patch adds two features, and those features are independent from a user
perspective. The primary feature is cursor readahead, and the secondary
feature is "ecpg --detect-cursor-resultset-size" (the referent of my above
"sqlerrd[2] compatibility stuff" reference). Each feature has independent
semantic implications when the application uses cursors on queries that call
volatile functions. Under --detect-cursor-resultset-size, we will execute
functions for all rows at OPEN time and again for each row at FETCH time.
When you declare a cursor with "READAHEAD n" and do not FETCH it to the end,
up to "n" unFETCHed rows will nonetheless have their functions executed. If
the volatile function is something like clock_timestamp(), the application
will observe the executions to have happened in clusters of "n" rather than in
step with the application's FETCH calls.

Your latest patch revision hints at the semantic implications for "ecpg
--detect-cursor-resultset-size", but it does not mention them for readahead.
Then again, perhaps it's sufficiently obvious to not warrant mention. Without
knowing internals, I would not expect users to guess the consequence of "ecpg
--detect-cursor-resultset-size". With readahead, it may be guessable enough.

Thanks,
nm