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

Поиск
Список
Период
Сортировка
От Michael Meskes
Тема Re: [BUGS] BUG #3244: problem with PREPARE
Дата
Msg-id 20070424074457.GB26599@feivel.credativ.de
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #3244: problem with PREPARE  ("William Lawrance" <bill.lawrance@bull.com>)
Ответы Re: [BUGS] BUG #3244: problem with PREPARE  (Bruce Momjian <bruce@momjian.us>)
Re: [BUGS] BUG #3244: problem with PREPARE  ("William Lawrance" <bill.lawrance@bull.com>)
Список 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@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: RETURN QUERY in PL/PgSQL?
Следующее
От: "Zeugswetter Andreas ADI SD"
Дата:
Сообщение: Re: [PATCHES] Full page writes improvement, code update