Re: Fix auto-prepare #2

Поиск
Список
Период
Сортировка
От Takahiro Itagaki
Тема Re: Fix auto-prepare #2
Дата
Msg-id 20100121110216.D16E.52131E4D@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Fix auto-prepare #2  (Boszormenyi Zoltan <zb@cybertec.at>)
Ответы Re: Fix auto-prepare #2  (Michael Meskes <meskes@postgresql.org>)
Список pgsql-hackers
Boszormenyi Zoltan <zb@cybertec.at> wrote:

> I only wanted to call ECPGprepare() in case it wasn't already prepared.
> ECPGprepare() also checks for the statement being already prepared
> with ecpg_find_prepared_statement() but in case it exists it
> DEALLOCATEs the statement and PREPAREs again so there's
> would be no saving for auto-prepare calling it unconditionally and
> we are doing a little extra work by calling ecpg_find_prepared_statement()
> twice. We need a common function shared by ECPGprepare() and
> ecpg_auto_prepare() to not do extra work in the auto-prepare case.
> 
> The attached patch implements this and also your leak fixes
> plus includes your change for the autoprep.pgc regression test.

Good. I think the patch is ready to commit.

A comment for committer (Michael?) :
I was cofused by the AddStmtToCache's 2nd argument "char *stmtID"
because it doesn't have a const. Should it be "const char *" ?
If the argument has a const, callers assume that they can pass
a not-strdup'ed string as the argument.

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center




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

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: HS/SR and smart shutdown
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Listen / Notify - what to do when the queue is full