Skip site navigation (1) Skip section navigation (2)

Re: Avoiding bad prepared-statement plans.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeroen Vermeulen <jtv(at)xs4all(dot)nl>, Greg Stark <gsstark(at)mit(dot)edu>, Bart Samwel <bart(at)samwel(dot)tk>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding bad prepared-statement plans.
Date: 2010-02-26 15:07:00
Message-ID: 27054.1267196820@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Alex Hunsaker <badalex(at)gmail(dot)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.  But even for client-submitted queries, it's often the case
that there is only one convenient way to do it given a particular
software stack on the client side.  If there is more than one way
they're usually radically different notationally, and some of them
might be vulnerable to SQL injection.  The comparable thing in plpgsql
is EXECUTE versus direct execution of a query: they're very different
notationally, so unpleasant to convert between, and it's easy to
create a security hole when interpolating parameters in EXECUTE.

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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-02-26 15:21:03
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Previous:From: Richard HuxtonDate: 2010-02-26 14:57:16
Subject: Re: Hot Standby query cancellation and Streaming Replication integration

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group