Am Dienstag, den 01.11.2005, 23:31 +0200 schrieb Yonatan Ben-Nes:
> Jim C. Nasby wrote:
> > On Tue, Nov 01, 2005 at 08:27:21PM +0200, Yonatan Ben-Nes wrote:
> >
> >>Won't that create a performance penalty to extremly dynamic sites cause
> >>the plan will be planned only once and the data may vary alot?
> >>Beside that I still won't have a solution to places where I create a
> >>query which can vary alot (JOIN diffrent tables, diffrent WHERE etc...),
> >>it doesn't seem logical to me to start and create all of the diffrent
> >>possibilites of queries when I create such an option at a site.
> >
> >
> > Yes, when you start getting into dynamically generated SQL you quickly
> > loose the performance benefit of prepared statements just because odds
> > are good that nothing else will use it. But you still have the benefit
> > of bound parameters and protection from injection.
>
> My problem with the dynamically generated SQL is that I'll have to
> create and maintain lots of prepared statements and be sure that I dont
> miss any available option, and also every time that ill have to do basic
> changes at the queries I'll have to update each one of those prepared
> statements.... it seems to me like of extra work for sites which can
> create many dynamic queries.
You could just wrap the creation and execution of your SQL in your
database abstraction layer. Where execute() prepares and then executes
and executemany() prepares and then runs an array of data to execute.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
