Re: DBD::PgSQL: More Queestions

Поиск
Список
Период
Сортировка
От Tim Bunce
Тема Re: DBD::PgSQL: More Queestions
Дата
Msg-id 20021120150213.GZ381@dansat.data-plan.com
обсуждение исходный текст
Ответ на Re: DBD::PgSQL: More Queestions  (Rudy Lippan <rlippan@remotelinux.com>)
Список pgsql-interfaces
On Wed, Nov 20, 2002 at 08:58:59AM -0500, Rudy Lippan wrote:
> On Wed, 20 Nov 2002, Tim Bunce wrote:
> 
> > > I notice that 
> > > DBD::ODBC, for example, doesn't appear to do anything special with 
> > > regard to comments. And if comments *are* supported by DBI, and DBD::Pg 
> > > is doing the right thing by watching out for them, wouldn't it be 
> > > smarter for DBD::Pg to cut them *out* of its internal copy of the SQL 
> > > statement so that dbd_st_execute() doesn't also have to deal with them?
> > 
> > Why should dbd_st_execute have to "deal" with them? The whole string
> > should just be sent off to the server.
> 
> PostgreSQL itself does not (yet) support placeholders, so DBD::Pg emulates
> them by scanning the string again in dbd_st_execute() looking for
> placeholders and substituting them quoted values of what was passed to 
> execute().

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.

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).

Tim.


В списке pgsql-interfaces по дате отправления:

Предыдущее
От: Tim Bunce
Дата:
Сообщение: Re: :PgSQL: More Queestions
Следующее
От: Rudy Lippan
Дата:
Сообщение: Re: :PgSQL: More Queestions