Re: Willing to fix a PQexec() in libpq module

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, wufei(dot)fnst(at)cn(dot)fujitsu(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Willing to fix a PQexec() in libpq module
Date: 2019-03-19 17:18:25
Message-ID: 21369.1553015905@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Finnerty 2019-03-19 17:23:55 Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Previous Message Jeremy Finzel 2019-03-19 17:16:34 Automated way to find actual COMMIT LSN of subxact LSN