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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Willing to fix a PQexec() in libpq module
Дата
Msg-id 21369.1553015905@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Willing to fix a PQexec() in libpq module  (Andres Freund <andres@anarazel.de>)
Ответы Re: Willing to fix a PQexec() in libpq module
Re: Willing to fix a PQexec() in libpq module
Список pgsql-hackers
Andres Freund <andres@anarazel.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


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

Предыдущее
От: Jeremy Finzel
Дата:
Сообщение: Automated way to find actual COMMIT LSN of subxact LSN
Следующее
От: Jim Finnerty
Дата:
Сообщение: Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?