Re: [GENERAL] ecpg problem
Michael Meskes wrote: On Fri, Feb 29, 2008 at 11:27:25AM -0500, Steve Clark wrote: Actually it appears to work in 8.2.5 but be broken in 8.2.6 and 8.3.0. Are you really sure? It appears to me that there was no change between 8.2.5 and 8.2.6 that could affect ecpg's handling of arrays of varchar. Michael I am pretty sure - but I upgraded my test system so I can't say for sure. Steve ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] ecpg problem
Michael Meskes wrote:
I just committed the attached small fix to CVS HEAD and the 8.3 branch.
This should fix your problem.
Michael
diff --exclude CVS -ru /home/postgres/pgsql-ecpg/preproc/type.c preproc/type.c
--- /home/postgres/pgsql-ecpg/preproc/type.c2007-12-21 15:33:20.0
+0100
+++ preproc/type.c 2008-03-02 11:49:11.0 +0100
@@ -259,7 +259,7 @@
ECPGdump_a_simple(o, name,
type-u.element-type,
-
type-u.element-size, type-size, NULL, prefix, type-lineno);
+
type-u.element-size, type-size, NULL, prefix, type-u.element-lineno);
if (ind_type != NULL)
{
Thank Michael,
I'll give it a try.
Steve
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [GENERAL] ecpg problem
I just committed the attached small fix to CVS HEAD and the 8.3 branch.
This should fix your problem.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
diff --exclude CVS -ru /home/postgres/pgsql-ecpg/preproc/type.c preproc/type.c
--- /home/postgres/pgsql-ecpg/preproc/type.c 2007-12-21 15:33:20.0 +0100
+++ preproc/type.c 2008-03-02 11:49:11.0 +0100
@@ -259,7 +259,7 @@
ECPGdump_a_simple(o, name,
type-u.element-type,
- type-u.element-size, type-size, NULL, prefix, type-lineno);
+ type-u.element-size, type-size, NULL, prefix, type-u.element-lineno);
if (ind_type != NULL)
{
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [GENERAL] ecpg problem
On Fri, Feb 29, 2008 at 11:27:25AM -0500, Steve Clark wrote: Actually it appears to work in 8.2.5 but be broken in 8.2.6 and 8.3.0. Are you really sure? It appears to me that there was no change between 8.2.5 and 8.2.6 that could affect ecpg's handling of arrays of varchar. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] ecpg problem
Steve Clark wrote:
Hello List,
Don't know whether anyone here can help but... We have some code that
has compiled and ran just
fine from postgresql 7.3.x thru 8.2.6. It uses embedded sql. I just
yesterday upgraded our test system to
8.3.0 and this code will no longer compile. Below is a standalone code
fragment in which I have removed
everything but what is causing the problem. Any help or ideas would be
appreciated.
exec sql include sqlca;
EXEC SQL WHENEVER NOT FOUND CONTINUE;
// this array is grown as messages from new units are received
// it is sorted by unit_serial_no ascending to support binary searches
int getUnitData()
{
exec sql begin declare section;
VARCHAR h_unit_serial_no [ 15+1];
// we do an array fetch on these 30 is the max number for these
int h_remote_int_netmask[4096];
int h_local_int_netmask [4096];
VARCHAR h_tunnel_active [4096][ 1+1];
VARCHAR h_tunnel_config_type[4096][ 1+1];
VARCHAR h_local_vpn_int_ip [4096][ 20+1];
VARCHAR h_local_vpn_ext_ip [4096][ 20+1];
VARCHAR h_remote_vpn_int_ip [4096][ 20+1];
VARCHAR h_remote_vpn_ext_ip [4096][ 20+1];
exec sql end declare section;
exec sql select tunnel_active,
tunnel_config_type,
host(local_int_gw_ip),
host(local_ext_gw_ip),
host(remote_int_gw_ip),
host(remote_ext_gw_ip),
masklen(remote_int_gw_ip),
masklen(local_int_gw_ip)
into:h_tunnel_active,
:h_tunnel_config_type,
:h_local_vpn_int_ip,
:h_local_vpn_ext_ip,
:h_remote_vpn_int_ip,
:h_remote_vpn_ext_ip,
:h_remote_int_netmask,
:h_local_int_netmask
from t_vpn_tunnel_status
where unit_serial_no = :h_unit_serial_no
order by oid;
/*limit 30;*/
return TRUE;
}
gmake -k ecpg_test.o
/usr/local/bin/ecpg -I/usr/local/include/pgsql -I/usr/local/include
ecpg_test.pgc
mkdep -O2 -Wall -DDEBUG -I../include -I/usr/local/include/pgsql
-I/usr/local/include -I../common crypt_file.c mailuser.c
srm2_monitor_server.c putfiles.c srm2_server_funcs.c escalate.c
packet_loss.c srm2_cron.c srm2_db_funcs.c srm2_monitor_db.c ecpg_test.c
g++ -O2 -Wall -DDEBUG -I../include -I/usr/local/include/pgsql
-I/usr/local/include -I../common -c ecpg_test.c
ecpg_test.pgc: In function `int getUnitData()':
ecpg_test.pgc:36: error: invalid application of `sizeof' to incomplete
type `varchar_h_tunnel_active'
ecpg_test.pgc:38: error: invalid application of `sizeof' to incomplete
type `varchar_h_tunnel_config_type'
ecpg_test.pgc:40: error: invalid application of `sizeof' to incomplete
type `varchar_h_local_vpn_int_ip'
ecpg_test.pgc:42: error: invalid application of `sizeof' to incomplete
type `varchar_h_local_vpn_ext_ip'
ecpg_test.pgc:44: error: invalid application of `sizeof' to incomplete
type `varchar_h_remote_vpn_int_ip'
ecpg_test.pgc:46: error: invalid application of `sizeof' to incomplete
type `varchar_h_remote_vpn_ext_ip'
gmake: *** [ecpg_test.o] Error 1
Compilation exited abnormally with code 2 at Fri Feb 29 09:59:10
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Actually it appears to work in 8.2.5 but be broken in 8.2.6 and 8.3.0.
Steve
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
[GENERAL] ecpg problem
Hello List,
Don't know whether anyone here can help but... We have some code that
has compiled and ran just
fine from postgresql 7.3.x thru 8.2.6. It uses embedded sql. I just
yesterday upgraded our test system to
8.3.0 and this code will no longer compile. Below is a standalone code
fragment in which I have removed
everything but what is causing the problem. Any help or ideas would be
appreciated.
exec sql include sqlca;
EXEC SQL WHENEVER NOT FOUND CONTINUE;
// this array is grown as messages from new units are received
// it is sorted by unit_serial_no ascending to support binary searches
int getUnitData()
{
exec sql begin declare section;
VARCHAR h_unit_serial_no [ 15+1];
// we do an array fetch on these 30 is the max number for these
int h_remote_int_netmask[4096];
int h_local_int_netmask [4096];
VARCHAR h_tunnel_active [4096][ 1+1];
VARCHAR h_tunnel_config_type[4096][ 1+1];
VARCHAR h_local_vpn_int_ip [4096][ 20+1];
VARCHAR h_local_vpn_ext_ip [4096][ 20+1];
VARCHAR h_remote_vpn_int_ip [4096][ 20+1];
VARCHAR h_remote_vpn_ext_ip [4096][ 20+1];
exec sql end declare section;
exec sql select tunnel_active,
tunnel_config_type,
host(local_int_gw_ip),
host(local_ext_gw_ip),
host(remote_int_gw_ip),
host(remote_ext_gw_ip),
masklen(remote_int_gw_ip),
masklen(local_int_gw_ip)
into:h_tunnel_active,
:h_tunnel_config_type,
:h_local_vpn_int_ip,
:h_local_vpn_ext_ip,
:h_remote_vpn_int_ip,
:h_remote_vpn_ext_ip,
:h_remote_int_netmask,
:h_local_int_netmask
from t_vpn_tunnel_status
where unit_serial_no = :h_unit_serial_no
order by oid;
/*limit 30;*/
return TRUE;
}
gmake -k ecpg_test.o
/usr/local/bin/ecpg -I/usr/local/include/pgsql -I/usr/local/include
ecpg_test.pgc
mkdep -O2 -Wall -DDEBUG -I../include -I/usr/local/include/pgsql
-I/usr/local/include -I../common crypt_file.c mailuser.c
srm2_monitor_server.c putfiles.c srm2_server_funcs.c escalate.c
packet_loss.c srm2_cron.c srm2_db_funcs.c srm2_monitor_db.c ecpg_test.c
g++ -O2 -Wall -DDEBUG -I../include -I/usr/local/include/pgsql
-I/usr/local/include -I../common -c ecpg_test.c
ecpg_test.pgc: In function `int getUnitData()':
ecpg_test.pgc:36: error: invalid application of `sizeof' to incomplete
type `varchar_h_tunnel_active'
ecpg_test.pgc:38: error: invalid application of `sizeof' to incomplete
type `varchar_h_tunnel_config_type'
ecpg_test.pgc:40: error: invalid application of `sizeof' to incomplete
type `varchar_h_local_vpn_int_ip'
ecpg_test.pgc:42: error: invalid application of `sizeof' to incomplete
type `varchar_h_local_vpn_ext_ip'
ecpg_test.pgc:44: error: invalid application of `sizeof' to incomplete
type `varchar_h_remote_vpn_int_ip'
ecpg_test.pgc:46: error: invalid application of `sizeof' to incomplete
type `varchar_h_remote_vpn_ext_ip'
gmake: *** [ecpg_test.o] Error 1
Compilation exited abnormally with code 2 at Fri Feb 29 09:59:10
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [GENERAL] ECPG problem with 8.3
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] ECPG problem with 8.3
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: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] ECPG problem with 8.3
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] ECPG problem with 8.3
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] ECPG problem with 8.3
On Sun, Jan 13, 2008 at 03:01:04PM +, 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: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] ECPG problem with 8.3
Michael Meskes wrote: On Sun, Jan 13, 2008 at 03:01:04PM +, 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/
Re: [GENERAL] ECPG problem with 8.3
- Original Message From: Peter Wilson [EMAIL PROTECTED] To: Michael Meskes [EMAIL PROTECTED]; 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*C code that I've worked with over the years uses a variable for the fetch count as well. It'd be nice if there was some way to support this convention directly in ECPG (assuming it doesn't create maintenance/security issues) for anyone porting applications 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] ECPG problem with 8.3
Peter Wilson [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] ECPG problem with 8.3
On Fri, Jan 11, 2008 at 11:51:08PM +, 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: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] ECPG problem with 8.3
Michael Meskes wrote: On Fri, Jan 11, 2008 at 11:51:08PM +, 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[GENERAL] 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
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
