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

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: Willing to fix a PQexec() in libpq module
Дата
Msg-id 20190319164346.GP10435@fetter.org
обсуждение исходный текст
Ответ на Re: Willing to fix a PQexec() in libpq module  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Willing to fix a PQexec() in libpq module
Список pgsql-hackers
On Tue, Mar 19, 2019 at 10:30:45AM -0400, Tom Lane wrote:
> Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> > At Tue, 19 Mar 2019 08:18:23 +0000, "Wu, Fei" <wufei.fnst@cn.fujitsu.com> wrote in
<52E6E0843B9D774C8C73D6CF64402F05621F0FFC@G08CNEXMBPEKD02.g08.fujitsu.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Banck
Дата:
Сообщение: Re: Offline enabling/disabling of data checksums
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Libpq support to connect to standby server as priority