Обсуждение: [ECPG] generates bad code on declare/open

How do I handle host variables passed in the where clause
of a declared cursor?  It seems "ecpg" 2.9 takes the declare/open
and puts the resulting code near the open.  This seems to be a bad
thing if the host variable is declared in a different block or function:

Consider...

func()
{  exec sql begin declare section;     int i;  exec sql end declare section;
  exec sql declare c1 cursor for select x from y where i = :i;
}
func2()
{  exec sql open c1;
}

...yields...
  /* exec sql begin declare section */


#line 3 "a.pgc"  int  i   ;
/* exec sql end declare section */
#line 4 "a.pgc"

  /* declare c1  cursor for select  x   from y where i  = ?   */
#line 6 "a.pgc"

}
func2()
{  { ECPGdo(__LINE__, NULL, "declare c1  cursor for select  x   from y where
i
= ?  ",  ECPGt_int,&(0~V7@0~V7@^P),1L,1L,sizeof(int),  ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EOIT,
ECPGt_EORT);}
#line 10 "a.pgc"

}

Obviously the precompiler has no knowledge of the local host variable
in the other function.

Tim Nelson

On Wed, Jan 09, 2002 at 12:06:52PM -0500, Tim Nelson wrote:
> How do I handle host variables passed in the where clause
> of a declared cursor?  It seems "ecpg" 2.9 takes the declare/open
> and puts the resulting code near the open.  This seems to be a bad
> thing if the host variable is declared in a different block or function:

This is not really bad code but a documented feature. PostgreSQL does not
have an "open cursor" statement, but instead opens the cursor when it is
declared. So what else can ecpg do other than moving the declaration to the
open statement? You cannot open the cursor when the declare is issued
because the declaration might be outside the scope of the executing
function.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Have there been any changes made to the "frontend/backend protocol" 
(messages & all that) for PostgreSQL 7.3?

Are there any changes brewing (perhaps for PostgreSQL 8.0)?

I ask because the PostgreSQL driver I have written for Smalltalk works 
at this level.

Thanks,   Bruce

Bruce Badger writes:

> Have there been any changes made to the "frontend/backend protocol"
> (messages & all that) for PostgreSQL 7.3?

Since there is no PostgreSQL 7.3 yet, I couldn't tell you, but there
haven't been any changes in 7.2 as compared to 7.1.  FWIW, I think there
*will* be some changes in 7.3, but it will be backward compatible.

-- 
Peter Eisentraut   peter_e@gmx.net

Bruce Badger wrote:
> Have there been any changes made to the "frontend/backend protocol" 
> (messages & all that) for PostgreSQL 7.3?
> 
> Are there any changes brewing (perhaps for PostgreSQL 8.0)?
> 
> I ask because the PostgreSQL driver I have written for Smalltalk works 
> at this level.

None I know of.  There is talk about taking the NAMEDATALEN from 32 to a
longer value, and that may affect NOTIFY protocol, but that is all I
know of.


--  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 Badger <bruce_badger@BadgerSE.com> writes:
> Have there been any changes made to the "frontend/backend protocol" 
> (messages & all that) for PostgreSQL 7.3?

Sorry, I don't have my crystal ball handy to prognosticate for 7.3 ;-).
There haven't been any changes as of 7.2, though.  There have been
additions; do you support MD5 password encryption, for example?

Sooner or later there will probably be major changes, whenever we get
sufficiently disgusted with the problems of COPY and so forth.  You'll
just have to keep your head up --- though we generally try to make the
backend backwards-compatible with old clients.  (AFAIK the backend still
accepts protocol 1.0 ... though it's untested for a long time, and
likely won't be fixed if it happens to break.)
        regards, tom lane