Re: DBD::PgSQL: More Queestions - Mailing list pgsql-interfaces

From David Wheeler
Subject Re: DBD::PgSQL: More Queestions
Date
Msg-id A1BF32B2-FCFD-11D6-8943-0003931A964A@wheeler.net
Whole thread Raw
In response to DBD::PgSQL: More Queestions  (David Wheeler <david@wheeler.net>)
Responses Re: DBD::PgSQL: More Queestions
List pgsql-interfaces
On Wednesday, November 20, 2002, at 07:02  AM, Tim Bunce wrote:

> Ah, okay.
>
> The goal is always to reduce the work that execute() does as far
> as possible. I'd suggest that the preparse code generate a list of
> the 'fragments' of SQL between the placeholders. All execute has
> to do is effectively join the parts together.

Ooh, hey, that's not a bad idea.

> But it's probably not worth worrying about. The cost of the scan
> is tiny and would be dwarfed by other issues like how you handle
> memory allocation (like, measure all fragments and placeholder values
> first then allocate and merge, or concatenate each part into an SV).

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?

Regards,

David

-- 
David Wheeler                                     AIM: dwTheory
david@wheeler.net                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e                                               Jabber:
Theory@jabber.org



pgsql-interfaces by date:

Previous
From: David Wheeler
Date:
Subject: Re: DBD::PgSQL: More Queestions
Next
From: David Wheeler
Date:
Subject: Re: DBD::PostgreSQL