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
|
Список | 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 по дате отправления: