Thread: ECPG - connection name in "EXEC SQL AT ... " statement
I've faced with the problem when trying to pass dynamically connection name
to DB into the "EXEC SQL AT ..." statement.
Let's revie the following example:
...
exec sql begin declare section;
char dbcn[17]; // connection name
char key[17]; // keyed query
char value[1024]; // result
exec sql end declare section;
strncpy(dbcn,connection_name, 16 ); dbcn[16] = '\0';
strncpy(key,param, 16 ); key[16] = '\0';
EXEC SQL AT :dbcn SELECT value INTO :value FROM table_name WHERE key = :key;
...
ecpg preprocessor produces the following ECPGdo call:
{ ECPGdo(__LINE__, dbcn, "select value from table_name where key = ? ", ECPGt_char,(dbcn),17L,1L,17*sizeof(char),
ECPGt_NO_INDICATOR,NULL , 0L, 0L, 0L, ECPGt_char,(key),17L,1L,17*sizeof(char), ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L,
ECPGt_EOIT,ECPGt_char,(value),1024L,1L,1024*sizeof(char), ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EORT);}
...
and during the execution it produces the following runtime error:"error [-201] Too many arguments in line 125."
Removing the ':' prefix from dbcn in EXEC statement results in interpreting
the dbcn literally, i.e., statement is translated to:
...
{ ECPGdo(__LINE__, "dbcn", "select value from table_name where key = ? ", ECPGt_char,(key),17L,1L,17*sizeof(char),
ECPGt_NO_INDICATOR,NULL , 0L, 0L, 0L, ECPGt_EOIT, ECPGt_char,(value),1024L,1L,1024*sizeof(char), ECPGt_NO_INDICATOR,
NULL, 0L, 0L, 0L, ECPGt_EORT);}
...
The workaround here is manually processing the resulting .c file (or via sed)
removing double quotes that surrounds the word dbcn.
...
!!!
Can anybody help in this matter ?
Is there any other solution ?
Regards,
Edward Pilipczuk
On Mon, Oct 22, 2001 at 10:34:59AM +0200, Edward Pilipczuk wrote:
> I've faced with the problem when trying to pass dynamically connection name
> to DB into the "EXEC SQL AT ..." statement.
Hmm, the AT statement was never designed to get a dynamic connection name.
It appears there was some interaction with other changes.
> { ECPGdo(__LINE__, dbcn, "select value from table_name where key = ? ",
It did accept "dbcn" as connection name, but also add it to the variable
list, which of course is not correct.
> Is there any other solution ?
Use a static connection name? :-)
Just joking, this is a bug that has to be fixed.
Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
> On Mon, Oct 22, 2001 at 10:34:59AM +0200, Edward Pilipczuk wrote:
> > I've faced with the problem when trying to pass dynamically connection name
> > to DB into the "EXEC SQL AT ..." statement.
>
> Hmm, the AT statement was never designed to get a dynamic connection name.
> It appears there was some interaction with other changes.
>
> > { ECPGdo(__LINE__, dbcn, "select value from table_name where key = ? ",
>
> It did accept "dbcn" as connection name, but also add it to the variable
> list, which of course is not correct.
>
> > Is there any other solution ?
>
> Use a static connection name? :-)
>
> Just joking, this is a bug that has to be fixed.
Can I have a TODO line for this fix?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Bruce Momjian wrote:
> > On Mon, Oct 22, 2001 at 10:34:59AM +0200, Edward Pilipczuk wrote:
> > > I've faced with the problem when trying to pass dynamically connection name
> > > to DB into the "EXEC SQL AT ..." statement.
> >
> > Hmm, the AT statement was never designed to get a dynamic connection name.
> > It appears there was some interaction with other changes.
> >
> > > { ECPGdo(__LINE__, dbcn, "select value from table_name where key = ? ",
> >
> > It did accept "dbcn" as connection name, but also add it to the variable
> > list, which of course is not correct.
> >
> > > Is there any other solution ?
> >
> > Use a static connection name? :-)
> >
> > Just joking, this is a bug that has to be fixed.
>
> Can I have a TODO line for this fix?
I can give you several TODO lines for ecpg (including this one)
- implement set descriptor, using descriptor
- make casts work in variable initializations
- allow variable to specify the connection name << this is it
- implement SQLDA (isn't that already in the TODO list?)
- design a way to select an array of strings into a variable without the need to
specify maximum length and count of strings
Added to TODO. Also, do we still use interfaces/ecpg/TODO. Seems we
should roll that into the main TODO like we did with jdbc.
---------------------------------------------------------------------------
> Bruce Momjian wrote:
>
> > > On Mon, Oct 22, 2001 at 10:34:59AM +0200, Edward Pilipczuk wrote:
> > > > I've faced with the problem when trying to pass dynamically connection name
> > > > to DB into the "EXEC SQL AT ..." statement.
> > >
> > > Hmm, the AT statement was never designed to get a dynamic connection name.
> > > It appears there was some interaction with other changes.
> > >
> > > > { ECPGdo(__LINE__, dbcn, "select value from table_name where key = ? ",
> > >
> > > It did accept "dbcn" as connection name, but also add it to the variable
> > > list, which of course is not correct.
> > >
> > > > Is there any other solution ?
> > >
> > > Use a static connection name? :-)
> > >
> > > Just joking, this is a bug that has to be fixed.
> >
> > Can I have a TODO line for this fix?
>
> I can give you several TODO lines for ecpg (including this one)
>
> - implement set descriptor, using descriptor
> - make casts work in variable initializations
> - allow variable to specify the connection name << this is it
> - implement SQLDA (isn't that already in the TODO list?)
> - design a way to select an array of strings into a variable without the need to
> specify maximum length and count of strings
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Bruce Momjian wrote: > Added to TODO. Also, do we still use interfaces/ecpg/TODO. Seems we > should roll that into the main TODO like we did with jdbc. I'd second that move. But Michaels (maintainer) vote on this is stronger than mine (contributor). Christof PS: Found a new TODO (while reading the 99 spec): - Solve cardinality>1 for input descriptors / variables (this one is tough, I can't even guess what it implies!)
> Bruce Momjian wrote: > > > Added to TODO. Also, do we still use interfaces/ecpg/TODO. Seems we > > should roll that into the main TODO like we did with jdbc. > > I'd second that move. But Michaels (maintainer) vote on this is stronger than mine > (contributor). I understand. The TODO in /ecpg is more of a implementation checklist rather than a TODO list. That is fine. > PS: Found a new TODO (while reading the 99 spec): > > - Solve cardinality>1 for input descriptors / variables (this one is tough, I can't > even guess what it implies!) Added to TODO. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, Oct 31, 2001 at 08:52:17AM +0100, Christof Petig wrote: > > Added to TODO. Also, do we still use interfaces/ecpg/TODO. Seems we > > should roll that into the main TODO like we did with jdbc. I agree. > I'd second that move. But Michaels (maintainer) vote on this is stronger than mine > (contributor). :-) Okay, here's the list from the actual TODo file: - ecpg should understand structure definitions outside a declare section. - sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified in a SET DESCRIPTOR statement will be ignored - error handling has to be improved by adding additional error-rules to the parser - usage of :var[:index] or :var[<integer>] as cvariable for an array var would be nice - add a semantic check level, e.g. check if a table really exists - remove space_or_nl and line_end from pgc.l - nested C comments do not work - SQLSTATE is missing Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
> On Wed, Oct 31, 2001 at 08:52:17AM +0100, Christof Petig wrote: > > > Added to TODO. Also, do we still use interfaces/ecpg/TODO. Seems we > > > should roll that into the main TODO like we did with jdbc. > > I agree. > > > I'd second that move. But Michaels (maintainer) vote on this is stronger than mine > > (contributor). > > :-) > > Okay, here's the list from the actual TODo file: > > - ecpg should understand structure definitions outside a declare section. > - sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified in a SET > DESCRIPTOR statement will be ignored > - error handling has to be improved by adding additional error-rules to > the parser > - usage of :var[:index] or :var[<integer>] as cvariable for an array var > would be nice > - add a semantic check level, e.g. check if a table really exists > - remove space_or_nl and line_end from pgc.l > - nested C comments do not work > - SQLSTATE is missing OK ecpg/TODO contents move to main TODO list. Thanks. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Thursday, 01 November 2001 21:07, you wrote: > > Okay, here's the list from the actual TODo file: > > > > - ecpg should understand structure definitions outside a declare section. > > - sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified in a > > SET DESCRIPTOR statement will be ignored > > - error handling has to be improved by adding additional error-rules to > > the parser > > - usage of :var[:index] or :var[<integer>] as cvariable for an array var > > would be nice > > - add a semantic check level, e.g. check if a table really exists > > - remove space_or_nl and line_end from pgc.l > > - nested C comments do not work > > - SQLSTATE is missing > > OK ecpg/TODO contents move to main TODO list. Thanks. And what about variable in connection name ? Edward Pilipczuk
> On Thursday, 01 November 2001 21:07, you wrote:
> > > Okay, here's the list from the actual TODo file:
> > >
> > > - ecpg should understand structure definitions outside a declare section.
> > > - sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified in a
> > > SET DESCRIPTOR statement will be ignored
> > > - error handling has to be improved by adding additional error-rules to
> > > the parser
> > > - usage of :var[:index] or :var[<integer>] as cvariable for an array var
> > > would be nice
> > > - add a semantic check level, e.g. check if a table really exists
> > > - remove space_or_nl and line_end from pgc.l
> > > - nested C comments do not work
> > > - SQLSTATE is missing
> >
> > OK ecpg/TODO contents move to main TODO list. Thanks.
>
> And what about variable in connection name ?
That was already on the TODO list:
o Allow variable to specify the connection name
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026