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

From: Andres Freund <andres(at)anarazel(dot)de>
To: "Wu, Fei" <wufei(dot)fnst(at)cn(dot)fujitsu(dot)com>
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Willing to fix a PQexec() in libpq module
Date: 2019-03-20 02:22:04
Message-ID: 20190320022204.vewun6swyhjdjzko@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(May called 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 other word, 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jamison, Kirk 2019-03-20 02:28:25 RE: Transaction commits VS Transaction commits (with parallel) VS query mean time
Previous Message Imai, Yoshikazu 2019-03-20 02:21:30 RE: speeding up planning with partitions