Re: [HACKERS] BUG #3244: problem with PREPARE

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: William Lawrance <bill(dot)lawrance(at)bull(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] BUG #3244: problem with PREPARE
Date: 2007-04-24 07:44:57
Message-ID: 20070424074457.GB26599@feivel.credativ.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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 should also be documented. The reason for this
behaviour is simply that ECPG prepare feature was added before the
backend had its own prepare feature. And no one changed it so far.

> There are several difficulties to be encountered when attempting to use
> this within a program using the ECPG interface. For example, the
> connection structure for PQlib isn't readily available, and the
> transaction semantics must be synchronized with ECPG's state. This did
> work, but it was fairly clumsy.

Right, that's what makes it non trivial.

> Since we wanted to do this in a cleaner manner, and also wished to avoid
> changing the applications if possible, we used the following approach:
>
> Within the "execute.c" module, we added routines to manage a cache
> of prepared statements. These routines are able to search, insert,
> and delete entries in the cache. The key for these cache entries is
> the text of the SQL statement as passed by ECPG from the application
> program.
>
> Within the same module, we replaced the "ECPGexecute" function.
> This is the function that is called to execute a statement after
> some preliminary housekeeping is done. The original "ECPGexecute"
> function constructs an ASCII string by replacing each host variable
> with its current value and then calling "PQexec". The new
> "ECPGexecute" function does the following:
>
> - build an array of the current values of the host variables.
>
> - search the cache for an entry indicating that this statement
> has already been prepare'd, via "PQprepare"
>
> - If no entry was found in the previous step, call "PQprepare"
> for the statement and then insert an entry for it into the
> cache. If this requires an entry to be re-used, execute a
> "DEALLOCATE PREPARE.." for the previous contents.
>
> - At this point, the SQL statement has been prepare'd by PQlib,
> either when the statement was executed in the past, or in
> the previous step.
>
> - call "PQexecPrepared", using the array of parameters built
> in the first step above.

Does this mean you prepare ALL statements? Or where you only talking
about statements that are prepared in the application?

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes(at)jabber(dot)org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Simon K 2007-04-24 09:56:06 BUG #3250: Different ResultSets btw JDBC Driver and pgAdmin3
Previous Message Tom Lane 2007-04-24 07:38:47 Re: BUG #3242: FATAL: could not unlock semaphore: error code 298

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas ADI SD 2007-04-24 08:08:44 Re: [HACKERS] Full page writes improvement, code update
Previous Message Tom Lane 2007-04-24 07:38:47 Re: BUG #3242: FATAL: could not unlock semaphore: error code 298