Re: ecpg weird behavior
От | Nicolas Bazin |
---|---|
Тема | Re: ecpg weird behavior |
Дата | |
Msg-id | 002b01c1cfa4$4e7e49d0$660d090a@software.ingenico.com.au обсуждение исходный текст |
Ответ на | ecpg weird behavior ("Nicolas Bazin" <nbazin@ingenico.com.au>) |
Ответы |
Re: ecpg weird behavior
|
Список | pgsql-interfaces |
----- Original Message ----- From: "Michael Meskes" <meskes@postgresql.org> To: "Nicolas Bazin" <nbazin@ingenico.com.au> Cc: "Thomas Lockhart" <thomas@fourpalms.org>; "Michael Meskes" <meskes@postgresql.org>; <pgsql-interfaces@postgresql.org> Sent: Wednesday, March 20, 2002 6:18 AM Subject: Re: [INTERFACES] ecpg weird behavior > On Mon, Mar 18, 2002 at 10:41:41AM +1100, Nicolas Bazin wrote: > > Yes I also have this issue. From what I read in the ecpg doc, indexed > > variables are not supported by ecpg and trying to compile the code definitle > > Yes, there's an open TODO for that. > > > proved it is not supported. The way I work arround it is to declare a local > > variable of the same type, copy the array element into this variable, > > perform the FECTH or SELECT and then copy the variable back into the array > > element. I guess the preprocessor could also generate the code. > > It should be even easier. I think the parser could handle that directly. > > > Another issue I had that ecpg does not support prepared statements. But I > > didn't have that many prepared statements so I just rewrote the code. > > ECPG just simulates a prepare statement, but that should not qualify as > "not support". So what didn't work? EXEC SQL PREPARE statement FROM :requete; EXEC SQL DECLARE curs_cartlstnoire CURSOR FOR statement; didn't get preprocessed. > > Michael > > -- > Michael Meskes > Michael@Fam-Meskes.De > Go SF 49ers! Go Rhein Fire! > Use Debian GNU/Linux! Use PostgreSQL! >
В списке pgsql-interfaces по дате отправления: