Thread: [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