I wrote:
> The easiest answer I can think of at the moment is to run parse analysis
> for a DECLARE CURSOR and then throw away the result. To avoid this
> overhead in cases where it's useless, we could probably teach analyze.c
> to do it only if p_variableparams is true (which essentially would me
l.org
Subject: Re: [HACKERS] [BUGS] BUG #3244: problem with PREPARE
On Mon, Apr 23, 2007 at 02:02:04PM -0700, William Lawrance wrote:
> Our first attempt to use the ECPG prepare interface revealed that ECPG
> doesn't use the PQlib prepare function. The ECPG prepare replaces any
> parameter
Michael Meskes wrote:
> On Mon, Apr 23, 2007 at 02:02:04PM -0700, William Lawrance wrote:
> > Our first attempt to use the ECPG prepare interface revealed that ECPG
> > doesn't use the PQlib prepare function. The ECPG prepare replaces any
> > parameters with their values and presents a new SQL stat
On Mon, Apr 23, 2007 at 02:02:04PM -0700, William Lawrance wrote:
> Our first attempt to use the ECPG prepare interface revealed that ECPG
> doesn't use the PQlib prepare function. The ECPG prepare replaces any
> parameters with their values and presents a new SQL statement to the
This is true and
We were about to submit a patch to ECPG to improve the performance
of embedded SQL, when we discovered that PREPARE had quit working.
Background:
We have a benchmark for a very large customer that consists of several
hundred programs containing several thousand embedded SQL statements.
In a thre
"William Lawrance" <[EMAIL PROTECTED]> writes:
> This program that does "PQprepare" and then
> "PQexecPrepared" has worked previously, but doesn't
> work now.
> ...
> strcpy(openStmt, "declare C1 cursor for select cola"
>" from tprep"
>" where
