Skip site navigation (1) Skip section navigation (2)

Re: ecpg weird behavior

From: "Nicolas Bazin" <nbazin(at)ingenico(dot)com(dot)au>
To: "Michael Meskes" <meskes(at)postgresql(dot)org>
Cc: <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: ecpg weird behavior
Date: 2002-03-14 06:16:41
Message-ID: 00f301c1cb1f$cebbe690$660d090a@software.ingenico.com.au (view raw or flat)
Thread:
Lists: pgsql-interfaces
----- Original Message -----
From: "Michael Meskes" <meskes(at)postgresql(dot)org>
To: "Nicolas Bazin" <nbazin(at)ingenico(dot)com(dot)au>
Cc: <pgsql-interfaces(at)postgresql(dot)org>
Sent: Thursday, March 14, 2002 1:16 AM
Subject: Re: [INTERFACES] ecpg weird behavior


> On Thu, Mar 07, 2002 at 10:14:41AM +1100, Nicolas Bazin wrote:
> > I'm porting an application from INFORMIX to Postgresql and have found
weird behaviour of ecpg:
> > - when using cursors, the fetch statement needs "into ..." which does
not comply with the SQL syntax,
>
> I'm not sure what you are talking about. FETCH with INTO does not comply
> to which standard? SQL3 for instance says:
>
> <fetch statement> ::=
>     FETCH [ [ <fetch orientation> ] FROM ]
>       <cursor name> INTO <fetch target list>
>
> If I omit the INTO how shall it know the variables?
It will know the variables when the cursor is declared. Here is the syntax
that we currently use with INFORMIX and it also corresponds to the syntax in
the PostgreSQL documentation:

EXEC SQL DECLARE curs_currency CURSOR FOR
    SELECT DISTINCT
FT_devises.dvs_devise,pays.pys_coddevalp,pays.pys_nbrdecimal
    INTO :pays.pys_coddevnum, :pays.pys_coddevalp, :pays.pys_nbrdecimal
    FROM pays, FT_devises WHERE FT_devises.dvs_code = :stpe.tpe_profdevise
    AND FT_devises.dvs_devise = pays.pys_coddevnum;

EXEC SQL FETCH curs_currency;


>
> > - a type definition needs to be written twice: the C  version and the
SQL version. It is easy to modify the preproc to only have the SQL
definition (I have done it and can submit a patch if anyone is interested),
>
> Yes, I am. Please send it to me directly at meskes(at)postgresql(dot)org(dot)
This patch breaks backward compatibility. The idea was to change the output
of the preproc when it parses EXEC SQL type mytpe is ... from comment to the
proper typedef definition. Then the typedef doesn't have to be added
manually. If you still want it, I can send it.

>
> > Also I have found a bug in the way the preproc  handles preproc
conditions "EXEC SQL IFDEF ...". I have submitted the patch to fix it to
hackers but it looks like it's been ignored.
>
> It seems you mail got delayed as it just arrived in my mailbox. But I
> take it this is the patch you already send me a few days ago (after all
> this mail I'm replying to was written March 7th). So it should be in CVS
> already.
Exactly.

>
> Michael
>
> --
> Michael Meskes
> Michael(at)Fam-Meskes(dot)De
> Go SF 49ers! Go Rhein Fire!
> Use Debian GNU/Linux! Use PostgreSQL!
>



In response to

Responses

pgsql-interfaces by date

Next:From: Constantin TeodorescuDate: 2002-03-14 06:52:38
Subject: Re: pgaccess error
Previous:From: Bruce MomjianDate: 2002-03-13 21:39:06
Subject: Re: [HACKERS] Additional fixes to ecpg - please apply patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group