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

From Tim Bunce
Subject Re: DBD::PgSQL: More Queestions
Date
Msg-id 20021120150213.GZ381@dansat.data-plan.com
Whole thread Raw
In response to Re: DBD::PgSQL: More Queestions  (Rudy Lippan <rlippan@remotelinux.com>)
List 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 by date:

Previous
From: Tim Bunce
Date:
Subject: Re: :PgSQL: More Queestions
Next
From: Rudy Lippan
Date:
Subject: Re: :PgSQL: More Queestions