Re: ECPG problem with 8.3

Поиск
Список
Период
Сортировка
От Peter Wilson
Тема Re: ECPG problem with 8.3
Дата
Msg-id fmd93f$2s54$1@news.hub.org
обсуждение исходный текст
Ответ на Re: ECPG problem with 8.3  (Michael Meskes <meskes@postgresql.org>)
Ответы Re: ECPG problem with 8.3  (Michael Meskes <meskes@postgresql.org>)
Список pgsql-general
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

В списке pgsql-general по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: ECPG problem with 8.3
Следующее
От: Tom Lane
Дата:
Сообщение: Re: tcp_keepalives_idle ignored