Re: Converting contrib SQL functions to new style - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Converting contrib SQL functions to new style
Date
Msg-id CA+TgmoaF_DKSPRnbkakkOufWMFpOBsA8fwE-mF0fF7aeH20zqg@mail.gmail.com
Whole thread Raw
In response to Re: Converting contrib SQL functions to new style  (Noah Misch <noah@leadboat.com>)
Responses Re: Converting contrib SQL functions to new style  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: sepgsql logging
Next
From: Bharath Rupireddy
Date:
Subject: Can a child process detect postmaster death when in pg_usleep?