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.
Maybe if we had that there would be more support for deprecating
the ability to send multiple queries in plain PQexec. It'd still
be a long time before we could turn it off though, at least by
default.
regards, tom lane
