Re: [HACKERS] Fix auto-prepare #2

2010-01-22 Thread Michael Meskes
Takahiro-san, > Good. I think the patch is ready to commit. Thanks for reviewing it. I just committed the patch. > 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 ar

Re: [HACKERS] Fix auto-prepare #2

2010-01-20 Thread Takahiro Itagaki
Boszormenyi Zoltan 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 > woul

Re: [HACKERS] Fix auto-prepare #2

2010-01-19 Thread Boszormenyi Zoltan
Hi, Takahiro Itagaki írta: > Hi, I'm reviewing your patch and have a couple of comments. > thanks for the review, comments below. > Boszormenyi Zoltan wrote: > > >> we have found that auto-prepare causes a problem if the connection >> is closed and re-opened and the previously prepared qu

Re: [HACKERS] Fix auto-prepare #2

2010-01-18 Thread Takahiro Itagaki
Hi, I'm reviewing your patch and have a couple of comments. Boszormenyi Zoltan wrote: > we have found that auto-prepare causes a problem if the connection > is closed and re-opened and the previously prepared query is issued > again. You didn't attach actual test cases for the bug, so I verifie