On Tue, Mar 19, 2019 at 01:18:25PM -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-03-19 13:59:34 -0300, Alvaro Herrera wrote:
> >> I suppose it can be argued that for the cases where they want that, it
> >> is not entirely ridiculous to have it be done with a different API call,
> >> say PQexecMultiple.
>
> > Sure, but what'd the gain be? Using PQexecParams() already enforces that
> > there's only a single command. Sure, explicit is better than implicit
> > and all that, but is that justification for breaking a significant
> > number of applications?
>
> Right, the tradeoff here comes down to breaking existing apps vs.
> adding security for poorly-written apps. Whether you think it's
> worthwhile to break stuff depends on your estimate of how common
> poorly-written apps are. To that point, I'd be inclined to throw
> David's previous comment back at him: they're likely not that
> common. A well-written app should probably be treating insecure
> inputs as parameters in PQexecParams anyhow, making this whole
> discussion moot.
>
> Having said that ... a better argument for a new API is that it
> could be explicitly designed to handle multiple queries, and in
> particular make some provision for returning multiple PGresults.
That sounds like it'd be *really* handy if one were building a
client-side retry framework. People will be doing (the equivalent of)
this as the vulnerabilities inherent in isolation levels lower than
SERIALIZABLE become better known.
https://www.cockroachlabs.com/blog/acid-rain/
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate