Re: Converting contrib SQL functions to new style

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Converting contrib SQL functions to new style
Дата
Msg-id CA+TgmoaF_DKSPRnbkakkOufWMFpOBsA8fwE-mF0fF7aeH20zqg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Converting contrib SQL functions to new style  (Noah Misch <noah@leadboat.com>)
Ответы Re: Converting contrib SQL functions to new style  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Apr 14, 2021 at 8:58 AM Noah Misch <noah@leadboat.com> wrote:
> Once CREATE EXTENSION is over, things are a great deal safer under this
> proposal, as you say.  I suspect it makes CREATE EXTENSION more hazardous.
> Today, typical SQL commands in extension creation scripts don't activate
> inexact argument type matching.  You were careful to make each script clear
> the search_path around commands deviating from that (commit 7eeb1d9).  I think
> "CREATE FUNCTION plus1dot1(int) RETURNS numeric LANGUAGE SQL RETURN $1 + 1.1;"
> in a trusted extension script would constitute a security vulnerability, since
> it can lock in the wrong operator.

I don't understand how that can happen, unless we've failed to secure
the search_path. And, if we've failed to secure the search_path, I
think we are in a lot of trouble no matter what else we do.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: sepgsql logging
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Can a child process detect postmaster death when in pg_usleep?