Re: DBD::PgSQL: More Queestions

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

In response to

Responses

Browse pgsql-interfaces by date

  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