ecpg question - Mailing list pgsql-general

From George Gensure
Subject ecpg question
Date
Msg-id Pine.GSO.4.53.0312230149100.17115@fury.csh.rit.edu
Whole thread Raw
Responses Re: ecpg question  (Michael Meskes <meskes@postgresql.org>)
Re: ecpg question  (Michael Meskes <meskes@postgresql.org>)
List pgsql-general
I wanted to ask this on here before going any further.

I've got functions that return rowsets, which from the psql shell require
me to write selects with AS TBL( ... ) to define the return types.

When I try to put a query together in ECPG to get values from these
functions, I discovered some nasty ecpg behavior.

EXEC SQL SELECT * FROM foo() AS TBL( c int );

compiles properly (?) to

{ ECPGdo(__LINE__, 0, 1, NULL, "select * from foo () as TBL ( c int  )
", ECPGt_EOIT, ECPGt_EORT);}

however
EXEC SQL SELECT * FROM foo() AS TBL( c int, i int );

or any other query with multiple columns to a TBL description causes a
segfault in ecpg.  It also concerns me that all other symbols are
dropped to lowercase, while TBL is still uppercase.  Leads me to
believe that TBL isn't getting parsed.  This was tested against cvs pgsql,
and the backtrace from the segfaults are consistent and appear below.

Program received signal SIGSEGV, Segmentation fault.
in strlen () from /usr/lib/libc.so.1
(gdb) bt
#0  in strlen () from /usr/lib/libc.so.1
#1  in cat2_str (str1=0xa5750 "c int ",
    str2=0x2c <Address 0x2c out of bounds>) at preproc.y:80
#2  in cat_str (count=3) at preproc.y:103
#3  in _end ()
#4  in main (argc=2, argv=0xxxxxxxxx) at ecpg.c:395

I tried picking the rules apart that call cat_str in this case, but I
can't really figure out where in preproc.y it gets called and screws that
second var argument to cat_str up.  Hopefully someone has dealt with this
before and can tell me why what I'm doing is wrong, or that I should send
this on to -hackers.

Thanks,
-George
werkt@csh.rit.edu

pgsql-general by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: PostgreSQL 7.4.1 Released
Next
From: Pavel Stehule
Date:
Subject: Re: CHECK versus a Table for an enumeration