Thread: ECPG problem with 8.3
I've just tried compiling our project against the 8.3RC1 code. This is the first
time I've tried any release of 8.3.
Several components use ECPG. I'm now getting an ECPG error. Compiling on 8.2.3
is fine. I've checked the 8.3 release documentation and there don't seem to be
any that change the ECPG interface - all the changes seem to be behind the
scenes. The biggest being a change to the backend protocol.
# gcc --version
gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# /usr/local/pgsql/bin/ecpg --version
ecpg (PostgreSQL 8.3RC1) 4.4.0
----- The error :
# make
make[1]: Entering directory `/var/build/whitebeam/templates/pgsql/common'
/usr/local/pgsql/bin/ecpg -t -o crbembsql.cxx -I /usr/local/pgsql/include
crbembsql.pgC
g++ -c crbembsql.cxx -o crbembsql.o
g++ -c -g -O2 -I/var/build/whitebeam/include -DHAVE_CONFIG_H
-I/usr/local/pgsql/include -I/usr/local/pgsql/include/server
-I/var/build/whitebeam/common -I/var/build/whitebeam/presentation
-I/usr/include/openssl -I/usr/local/pgsql/include -I
/var/build/whitebeam/templates -I ../common crbembsql.cxx -o crbembsql.o
crbembsql.pgC: In member function `BOOL crbembsql::gensql(const char*, int,
BOOL, CrbString*)':
crbembsql.pgC:254: error: invalid conversion from `int' to `ECPG_statement_type'
crbembsql.pgC:254: error: initializing argument 6 of `bool ECPGdo(int, int,
int, const char*, char, ECPG_statement_type, const char*, ...)'
make[1]: *** [crbembsql.o] Error 1
make[1]: Leaving directory `/var/build/whitebeam/templates/pgsql/common'
make: *** [all] Error 2
------- The relevant lines in crbembsql.pgQ - the second is line 254
EXEC SQL PREPARE U1 FROM :sl_sql;
EXEC SQL EXECUTE U1;
------- The output for those lines from the ECPG preprocessor :
{ ECPGprepare(__LINE__, NULL, 0, "u1", sl_sql);}
#line 253 "crbembsql.pgC"
{ ECPGdo(__LINE__, 0, 1, NULL, 0, 1, "u1", ECPGt_EOIT, ECPGt_EORT);}
#line 254 "crbembsql.pgC"
----------- PROTOTYPE for ECPGdo taken from
/usr/local/pgsql/include/ecpglib.h bool ECPGdo(const int, const int, const int,
const char *, const char, const enum ECPG_statement_type, const char *,...);
----------
The changes to the ECPGdo prototype were made during 8.3 development
(REL8_2_STABLE) and were checked in 2007/08/14 (version 1.71 of ecpglib.h) by
user 'meskes'.
----------
Any suggestions very much appreciated!
Peter Wilson
--
http://www.whitebeam.org - OpenSource Web Application Server
On Fri, Jan 11, 2008 at 11:51:08PM +0000, Peter Wilson wrote: > I've just tried compiling our project against the 8.3RC1 code. This is > the first time I've tried any release of 8.3. > ... > crbembsql.pgC:254: error: invalid conversion from `int' to `ECPG_statement_type' > crbembsql.pgC:254: error: initializing argument 6 of `bool ECPGdo(int, > int, int, const char*, char, ECPG_statement_type, const char*, ...)' It seems that some compilers don't like int/enum aliasing here. I changed this in CVS could you please re-try? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes wrote:
> On Fri, Jan 11, 2008 at 11:51:08PM +0000, Peter Wilson wrote:
>> I've just tried compiling our project against the 8.3RC1 code. This is
>> the first time I've tried any release of 8.3.
>> ...
>> crbembsql.pgC:254: error: invalid conversion from `int' to `ECPG_statement_type'
>> crbembsql.pgC:254: error: initializing argument 6 of `bool ECPGdo(int,
>> int, int, const char*, char, ECPG_statement_type, const char*, ...)'
>
> It seems that some compilers don't like int/enum aliasing here. I
> changed this in CVS could you please re-try?
>
> Michael
Thank you Michael,
that fixes that problem. My build now gets further, but I get an error and a
seg-fault later in the build.
I have a file that contains the following line :
EXEC SQL FETCH ABSOLUTE :count SEARCHCURSOR INTO
:db.contact_id, :db.uname, :db.type, :db.parent,
:db.name, :db.phone, :db.fax, :db.email, :db.description,
:db.custom_data, :db.value, :db.relevance,
:db.parentName :vl_parentName,
:db.keywords :vl_keywords,
:membOfRecordCount;
this has worked in every version of ECPG since 7.4 (when we started using
Postgres). I now get the following error :
$ /usr/local/pgsql/bin/ecpg -t -o contactRecord.cxx -I
/usr/local/pgsql/pgsql/include contactRecord.pgC
Starting program: /usr/local/pgsql.8.3.rc1.patch/bin/ecpg -t -o
contactRecord.cxx -I /usr/local/pgsql/include contactRecord.pgC
contactRecord.pgC:1338: ERROR: fetch/move count must not be a variable.
gmake[1]: *** [contactRecord.cxx] Segmentation fault
gmake[1]: *** Deleting file `contactRecord.cxx'
gmake[1]: Leaving directory `/var/build/whitebeam/templates/pgsql/contacts-pgsql'
gmake: *** [all] Error 2
-------------
Running under GDB gives a stack trace as :
Program received signal SIGSEGV, Segmentation fault.
0x00bd0da3 in strlen () from /lib/tls/libc.so.6
(gdb) i s 5
#0 0x00bd0da3 in strlen () from /lib/tls/libc.so.6
#1 0x080494b1 in cat2_str (str1=0x969bae0 "fetch", str2=0x0) at preproc.y:105
#2 0x0804955e in cat_str (count=4) at preproc.y:128
#3 0x0805027e in base_yyparse () at preproc.y:2299
#4 0x08067f12 in main (argc=7, argv=0xfef93284) at ecpg.c:457
(gdb) i s
#0 0x00bd0da3 in strlen () from /lib/tls/libc.so.6
#1 0x080494b1 in cat2_str (str1=0x969bae0 "fetch", str2=0x0) at preproc.y:105
#2 0x0804955e in cat_str (count=4) at preproc.y:128
#3 0x0805027e in base_yyparse () at preproc.y:2299
#4 0x08067f12 in main (argc=7, argv=0xfef93284) at ecpg.c:457
-----------------------
Apart from the seg-fault, is there any particular reason I can't use a variable
in the FETCH anymore? It's always worked in the past and would seem to be an
important capability.
Pete
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. > 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. Hope this helps. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
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
----- Original Message ----
> From: Peter Wilson <petew@yellowhawk.co.uk>
> To: Michael Meskes <meskes@postgresql.org>; pgsql-general@postgresql.org
> Sent: Monday, January 14, 2008 8:41:12 AM
> Subject: Re: [GENERAL] ECPG problem with 8.3
>
> 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?
I'd like to add to this discussion from an Oracle Pro*C (Oracle's name for embedded SQL) perspective. Most of the
Pro*Ccode that I've worked with over the years uses a variable for the fetch count as well. It'd be nice if there was
someway to support this convention directly in ECPG (assuming it doesn't create maintenance/security issues) for anyone
portingapplications from Oracle to Postgresql.
Regards,
Shelby Cain
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Peter Wilson <petew@yellowhawk.co.uk> writes:
> Michael Meskes wrote:
>> 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?
I'm concerned about this too. We'll at least have to call this out as
an incompatibility in 8.3, and it seems like a rather unnecessary step
backwards.
regards, tom lane
On Mon, Jan 14, 2008 at 10:57:45AM -0500, Tom Lane wrote: > I'm concerned about this too. We'll at least have to call this out as > an incompatibility in 8.3, and it seems like a rather unnecessary step > backwards. I thought I had send an email asking for comments back when this was implemented. But given that I cannot this email anymore I wonder if it really went out. My bay, sorry. Given that people seem to use this feature I'm more than willing to implement it, although it might become a bit hackish. Given that fetch is not a preparable statement we can live with the slightly inconsistent variable handling I think. Expect a patch soon. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
them. Every one can say this; every one can call himself a prophet. But I see that Christian religion wherein prophecies are fulfilled; and that is what every one cannot do. 694. And what crowns all this is prediction, so that it should not be said that it is chance which has done it? Whosoever, having only a week to live, will not find out that it is expedient to believe that all this is not a stroke of chance... Now, if the passions had no hold on us, a week and a hundred years would amount to the same thing. 695. Prophecies.--Great Pan is dead. 696. Susceperunt verbum cum omni aviditate, scrutantes Scripturas, si ita se haberent.[138] 697. Prodita lege. Impleta cerne. Implenda collige.[139] 698. We understand the prophecies only when we see the events happen. Thus the proofs of retreat, discretion, silence, etc., are proofs only to those who know and believe them. Joseph so internal in a law so external. Outward penances dispose to inward, as humiliations to humility. Thus the... 699. The synagogue has preceded the church; the Jews, the Christians. The pr
That it had been her opinion, till now, she was not guilty of Adam's sin, nor any way concerned in it, because she was not active in it; but that now she saw she was guilty of that sin, and all over defiled by it; and the sin which she brought into the world with her, was alone sufficient to condemn her. On the Sabbath-day she was so ill, that her friends thought it best that she should not go to public worship, of which she seemed very desirous: but when she went to bed on the Sabbath night, she took up a resolution, that she would the next morning go to the minister, hoping to find some relief there. As she awakened on Monday morning, a little before day, she wondered within herself at the easiness and calmness she felt in her mind, which was of that kind she never felt before. As she thought of this, such words as these were in her mind: The words of the Lord are pure words, health to the soul, and marrow to the bones: and then these words, The blood of Christ cleanses from all sin; which were accompanied with a lively sense of the excellency of Christ, and His sufficiency to satisfy for the sins of the whole world. She then thought of that expression, It is a pleasant thing for the eyes to behold the sun; which words then seemed to her to be very app
Michael Meskes wrote: > On Mon, Jan 14, 2008 at 10:57:45AM -0500, Tom Lane wrote: > >> I'm concerned about this too. We'll at least have to call this out as >> an incompatibility in 8.3, and it seems like a rather unnecessary step >> backwards. >> > > Given that people seem to use this feature I'm more than willing to > implement it, although it might become a bit hackish. Given that fetch > is not a preparable statement we can live with the slightly inconsistent > variable handling I think. > > Expect a patch soon. > > Michael > I've just tested my original un-tweaked ECPG application code against 8.3RC2 and everything compiles and runs fine - including the variable count argument. Thanks very much Michael Pete