Re: DBD::PgSQL: More Queestions
От | David Wheeler |
---|---|
Тема | Re: DBD::PgSQL: More Queestions |
Дата | |
Msg-id | A1BF32B2-FCFD-11D6-8943-0003931A964A@wheeler.net обсуждение исходный текст |
Ответ на | DBD::PgSQL: More Queestions (David Wheeler <david@wheeler.net>) |
Ответы |
Re: DBD::PgSQL: More Queestions
|
Список | 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 по дате отправления: