Re: Avoiding bad prepared-statement plans. - Mailing list pgsql-hackers

From Alex Hunsaker
Subject Re: Avoiding bad prepared-statement plans.
Date
Msg-id 34d269d41002260727h4f85286awd369ba01f895f169@mail.gmail.com
Whole thread Raw
In response to Re: Avoiding bad prepared-statement plans.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Feb 26, 2010 at 08:07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alex Hunsaker <badalex@gmail.com> writes:
>> Let me see if I can sum up what I was trying to say:
>> [ this can be solved by using or avoiding prepared statements ]
>
> Not really.  The place where that argument really fails is inside
> server-side functions: you don't get to use query submission protocol
> there.

| You look around, its dark... You notice someone coming towards you.
He tosses you a torch.  You kindly thank him.

Ahh.  ISTM re-planning those every time is entirely the wrong knob.

> If there is more than one way
> they're usually radically different notationally, and some of them
> might be vulnerable to SQL injection.

Good point.  However this is why I was talking about client side
drivers, they can provide an api to do this correctly and
conveniently.  The fact that some have not might hint that its not
really worth it most of the time?

> I think this is basically a planner problem and should be fixed in the
> planner, not by expecting users to make significant changes in
> application logic in order to create an indirect effect.

Well, of course you do.  We all know how you feel about planner hints
:) [ Tongue-in-cheek ]

Anyway, I completely agree-- its a much more elegant and workable solution.


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Next
From: Greg Stark
Date:
Subject: Re: A thought on Index Organized Tables