Re: ecpg weird behavior - Mailing list pgsql-interfaces

From Nicolas Bazin
Subject Re: ecpg weird behavior
Date
Msg-id 002b01c1cfa4$4e7e49d0$660d090a@software.ingenico.com.au
Whole thread Raw
In response to ecpg weird behavior  ("Nicolas Bazin" <nbazin@ingenico.com.au>)
Responses Re: ecpg weird behavior
List 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 by date:

Previous
From: "Nicolas Bazin"
Date:
Subject: Re: ecpg weird behavior
Next
From: Hal Davison
Date:
Subject: Re: ecpg weird behavior