On Tue, Mar 19, 2019 at 01:18:25PM -0400, Tom Lane wrote: > Andres Freund <and...@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
