Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
Date
Msg-id CA+TgmoaDoVtMnfKNFm-iyyCSp=FPiHkfU1AXuEHJqmcLTAX6kQ@mail.gmail.com
Whole thread Raw
In response to Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)  (Dave Cramer <pg@fastcrypt.com>)
List pgsql-hackers
On Wed, Jul 10, 2019 at 9:59 AM Dave Cramer <pg@fastcrypt.com> wrote:
> I'm still a bit conflicted about what to do with search_path as I do believe this is potentially a security issue.
> It may be that we always want to report that and possibly back patch it.

I don't see that as a feasible option unless we make the logic that
does the reporting smarter.  If it changes transiently inside of a
security-definer function, and then changes back, my recollection is
that right now we would report both changes.  I think that could cause
a serious efficiency problem if you are calling such a function in a
loop.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Tom Lane
Date:
Subject: Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)