Re: Fix auto-prepare #2

From: Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: Michael Meskes <meskes(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org, Hans-Juergen Schoenig <hs(at)cybertec(dot)at>
Subject: Re: Fix auto-prepare #2
Date: 2010-01-21 02:02:16
Message-ID: 20100121110216.D16E.52131E4D@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Boszormenyi Zoltan <zb(at)cybertec(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2010-01-21 02:06:57 Re: Listen / Notify - what to do when the queue is full
Previous Message Mark Kirkwood 2010-01-21 01:59:00 Re: HS/SR and smart shutdown