Re: Willing to fix a PQexec() in libpq module - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Willing to fix a PQexec() in libpq module
Date
Msg-id 20190320022204.vewun6swyhjdjzko@alap3.anarazel.de
Whole thread Raw
In response to RE: Willing to fix a PQexec() in libpq module  ("Wu, Fei" <wufei.fnst@cn.fujitsu.com>)
List pgsql-hackers
Hi,

On 2019-03-20 02:19:54 +0000, Wu, Fei wrote:
> Hi, thanks for all replies.
> According to all your discussions, Maybe the problems is that
> 1) keep modifications just in client side;
> 2) modifications VS client current applications
> 
> Maybe we could create a new function(May called PQexecSafe() ) just likes PQexec() but with additional input
argument(Maycalled issafe) to switch whether allowing at most one SQL command.
 
> In that way, clients who want the safe feature just use the new function PQexecSafe() with issafe set true,
> The others can choose:
> 1) just use the old version PQexec(),
> 2) using PQexecSafe() with issafe set false
> 
> Then, we strongly recommended using PQexecSafe(),and PQexec() keep in use but labeled deprecated in documents. In
otherword, give client the time to choose and modify their applications if then want use the safe feature.
 

We already have PQexecParams(). And there's already comments explaining
the multi-statement behaviour in the docs.  Do you see an additional
advantage in your proposal?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: "Imai, Yoshikazu"
Date:
Subject: RE: speeding up planning with partitions
Next
From: "Jamison, Kirk"
Date:
Subject: RE: Transaction commits VS Transaction commits (with parallel) VSquery mean time