From: | David Wheeler <david(at)wheeler(dot)net> |
---|---|
To: | Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> |
Cc: | 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 03:02:12 |
Message-ID: | A1BF32B2-FCFD-11D6-8943-0003931A964A@wheeler.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)wheeler(dot)net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)org
From | Date | Subject | |
---|---|---|---|
Next Message | David Wheeler | 2002-11-21 03:02:51 | Re: DBD::PostgreSQL |
Previous Message | David Wheeler | 2002-11-21 02:03:00 | Re: DBD::PgSQL: More Queestions |