From: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
---|---|
To: | David Wheeler <david(at)wheeler(dot)net> |
Cc: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, Rudy Lippan <rlippan(at)remotelinux(dot)com>, dbi-dev(at)perl(dot)org, pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: DBD::PgSQL: More Queestions |
Date: | 2002-11-21 09:44:39 |
Message-ID: | 20021121094439.GH381@dansat.data-plan.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
On Wed, Nov 20, 2002 at 07:02:12PM -0800, David Wheeler wrote:
> On Wednesday, November 20, 2002, at 07:02 AM, Tim Bunce wrote:
>
> Hrm, yes, good point. If I end up using PostgtreSQL 7.3's server-side
> prepare, though, I'll likely to something similar to this, though, as
> the execute syntax is (roughly):
>
> EXECUTE prepared_statement_name('param1', 'param2', 'paramn')
>
> So I would just have to append the escaped parameters in turn to
> "EXECUTE prepared_statement_name(" plus a closing ")".
>
> I need to think about how to create a prepared statement name, though.
> Some sort of hash (like MD5) would be good, but that might incur too
> much overhead. Ideas?
MD5 is pretty quick and the base64 result string is short.
But if prepared_statement_name's are local to the session then
you could just use a sequential integer. When a statement handle
is destroyed then you can tell the server to discard the statement.
You could also let the application specify a name:
$dbh->prepare("...", { pg_sth_name => "..." });
Tim.
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Bunce | 2002-11-21 09:47:09 | Re: DBD::PgSQL: More Queestions |
Previous Message | Tim Bunce | 2002-11-21 09:32:43 | Re: :PgSQL: More Queestions |