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

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 16:43:46
Message-ID: 20190319164346.GP10435@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 19, 2019 at 10:30:45AM -0400, Tom Lane wrote:
> Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> > At Tue, 19 Mar 2019 08:18:23 +0000, "Wu, Fei" <wufei(dot)fnst(at)cn(dot)fujitsu(dot)com> wrote in <52E6E0843B9D774C8C73D6CF64402F05621F0FFC(at)G08CNEXMBPEKD02(dot)g08(dot)fujitsu(dot)local>
> >> I will try to fix it~
>
> > I don't oppose that, but as the discussion linked from there [1],
> > psql already has a feature that sends multiple statements by one
> > PQexec() in two ways. Fixing it means making the features
> > obsolete.
>
> Yeah, the problem here is that a lot of people think that that's
> a feature not a bug. You certainly can't get away with just summarily
> changing the behavior of PQexec without any recourse. Maybe there
> would be acceptance for either of
>
> (1) a different function that is like PQexec but restricts the
> query string
>
> (2) a connection option or state variable that affects PQexec's
> behavior --- but it probably still has to default to permissive.
>
> Unfortunately, if the default behavior doesn't change, then there's little
> argument for doing this at all. The security reasoning behind doing
> anything in this area would be to provide an extra measure of protection
> against SQL-injection attacks on carelessly-written clients, and of course
> it's unlikely that a carelessly-written client would get changed to make
> use of a non-default feature.

It's also unlikely that writers and maintainers of carelessly-written
clients are our main user base. Quite the opposite, in fact. Do we
really need to set their failure to make an effort as a higher
priority than getting this fixed?

I think the answer is "no," and we should deprecate this misfeature.
It's bad enough that we'll be supporting it for five years after
deprecating it, but it's worse to leave it hanging around our necks
forever. https://en.wikipedia.org/wiki/Albatross_(metaphor)

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-03-19 16:45:09 Re: Libpq support to connect to standby server as priority
Previous Message Michael Banck 2019-03-19 16:30:16 Re: Offline enabling/disabling of data checksums