Re: Fix auto-prepare #2 - Mailing list pgsql-hackers

From Takahiro Itagaki
Subject Re: Fix auto-prepare #2
Date
Msg-id 20100121110216.D16E.52131E4D@oss.ntt.co.jp
Whole thread Raw
In response to Re: Fix auto-prepare #2  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: Fix auto-prepare #2
List 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 by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: HS/SR and smart shutdown
Next
From: Jeff Davis
Date:
Subject: Re: Listen / Notify - what to do when the queue is full