Date: Thu, 21 Nov 2002 09:44:39 +0000
From: Tim Bunce <Tim.Bunce@pobox.com>
To: David Wheeler <david@wheeler.net>
Cc: Tim Bunce <Tim.Bunce@pobox.com>,
	Rudy Lippan <rlippan@remotelinux.com>, dbi-dev@perl.org,
	pgsql-interfaces@postgresql.org
Subject: Re: DBD::PgSQL: More Queestions
Message-ID: <20021121094439.GH381@dansat.data-plan.com>
References: <20021120150213.GZ381@dansat.data-plan.com>
	<A1BF32B2-FCFD-11D6-8943-0003931A964A@wheeler.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <A1BF32B2-FCFD-11D6-8943-0003931A964A@wheeler.net>
User-Agent: Mutt/1.4i

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.