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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
