Michael Meskes wrote:
> On Sun, Jan 13, 2008 at 03:01:04PM +0000, Peter Wilson wrote:
>> that fixes that problem. My build now gets further, but I get an error
>> and a seg-fault later in the build.
>
> Whow, you're really stress testing it. Thanks a lot! This is what we
> need.
I have to say I didn't write the original code - so I'm not particularly an
expert in this area. I just get to maintain it and keep it working with newer
releases of Postgres!
>
>> Apart from the seg-fault, is there any particular reason I can't use a
>
> The segfault is fixed in CVS. Reason was that on finding the variable it
> set an error message but not the normal return value and then tried to
> proceed anyway.
>
>> variable in the FETCH anymore? It's always worked in the past and would
>> seem to be an important capability.
>
> Yes. ECPG move to the latest backend protocol version to be able to
> prepare statements correctly. However, with this protocol my own
> addition to the standard, namely a variable as fetch count, is not
> supported anymore. But there is a simple workaround. Just sprintf the
> statement to a string and thereby replace the count variable with its
> content and then EXEC SQL EXECUTE the string variable should do the job.
Fetch with a variable seems to be almost the only useful way of using FETCH
ABSOLUTE (or any of the variants that have count parameter).
For backwards compatibility wouldn't it be better to do the sprintf in the ECPG
preprocessor if the count is a variable rather than generate an error? In that
way none of the existing applications would break. I think it's always better to
keep the application interface the compatible with existing applications, even
if that means a little behind the scenes glue!
>
> Hope this helps.
>
> Michael
Thanks again for your help :-)
Pete
